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Preface 



This report aocuments the results of a 1973 study to 
identify a set of security enhancements for Honeywell's Multics 
operating system. These enhancements were derived from the 
Department of Oefense Information Security Program. The purpose 
of these enhancements was to permit users of two different 
security levels to simultaneously access classified information 
stored on the Multics system at the Air Force Data Services 
Center (AFOSC). This report served as a design document for the 
subsequent implementation of the security enhancements for use at 
the AFDSC. 

The implementation of the cesign was based upon the 
"non-malicious" user concept. This concept is predicated open 
the assumption that none of the user pooulation woulo attempt 
malicious* concerted efforts tc circumvent the enhanced security 
controls. The issues of guaranteeing the impenetrability of the 
security enhancements were not completely addressee* and the 
report makes no claim to the system's imoenet rab i I i ty. However, 
the proposea security controls are thought to be representative 
of those controls which coo Id be provided on a certifiably secure 
system. The issues involved in the development of a certifiably 
secure system are the subject of a separate effort sponsored by 
the Information Systems Technology Applications Office of tf-e Air 
Force's Electronic Systems Division. 

During the course of the implementation of the security 
enhancements proposed in this report* several minor deslcn 
changes were made. This report has not been updateo to reflect 
these changes. This reoort should be taken neither as a precise 
description of the enhanced Multics system implemented for AFDSC 
nor as a description of Honeywell's Multics product— current or 
future. 






INTRODUCTION 



Honeywell participated in a J clnt Security Oesign Analysis with 
the Air Force to evaluate the requirements for providing a 
two-level security system on Multics. The primary goal was to 
develop a high level design for modifications to the Multics 
system to support a two-level security environment. This effort 
is a first step on the path to a certified secure system. 

The analysis was conducted by a team composed of representatives 
from groups active in the computer security field. Team members 
weret 

USAF AFOSC Capt. F. Wah Leong 

Caot. Oave Schofer 

USAF ESO Major Roger Sche II 

Lt. Paul Karg^ 

MITRE Corp. Steven Lipner 

Morrie Gasser 
Edmund Burke 

Honeywell 0S0 Jerold Whitmcre 

Paul Green 
Douglas Hunt 
Jerry Stern 

Honeywell CISL Andre Bensoussan 

Andrew Kobziar 

The Security Design Analysis covered the period frorr 10 July 1973 
through 8 October 1973. The minutes of the weekly meetings are 
not part of this report. 

This report was written by Honeywell personnel witl~ review and 
guidance from the other team members. Responsibl I ty for errors 
and omissions remains strictly with Honeywell. 

Suggestions and design decisions contained in this reoort are not 
binding on either the Air Force or on Honeywell. 






SCOPE OF THE SECURITY OESIGN ANALYSIS 



i«l laentif Ication and Authority 

The authority for this Security Design Analysis is contained 
in contract number F19628-73-0- 00 87. The Design Analysis 
task has been conducted as a Joint effort of Honeywell 
Information Systems Inc., Oata Systems Operations? Air 
Force Oata Services Center; Air Force Electronics Systeirs 
Oivision <MCIT>; and MITRE Corporation. 



1.2 Purpose 

1.2.1 Task Description 



The primary task is to examine t*"e problems and implications 
of operating the Honeywell Multics System in a restricted 
multi-level security mode for Secret and Top Secret cleared 
users. The primary criterion to be used in evaluating 
solutions to various problems is that the system should 
provide reasonable assurance trat no Top Secret information 
can be compromised to a Secret cleared person. This means 
that on a single Multics system, within design constraints, 
there should be no Information Daths between users taving 
different clearances which do not exist between users of 
physically separate dedicatee computer systems. 

With these problems in mind, the team looked for 
modifications to the Multics Operating System which will 
correct these problems, insofar as possible, and yet 
maintain the current user interface ano functional 
capabilities of Multics. Specific design goals included: 

1. Oesign to the requirements of the Air Force Oata 
Services center RFP Not F19628-73-R-002** . 

2. Oesign the basic security controls as an integral part 
of the Multics system. 

3. Provide a design which may be extended for additional 
security enhancements. 






*♦. Provide a generalized design that may be adapted for 
other OoO and commercial applications of the security 
system. 

1.2.2 Specific Exclusions from the Design Analysis 

Certain problems of multi-level security AOP operation and 
extensions of basic irultl-level security controls here known 
at the start of the Design Analysis and were specifically 
excluded. These are described in the following paragraphs. 



1.2.2.1 Certification 

The task of certifying tre correctness of any Implementation 
of the multi-level security system design proposed in this 
report is. of course, beyond the scope of the Design 
Analysis. No hardware modifications are in fact required. 
In spite of a conceptually correct design, an actual 
implementation could conceivably contain programming errors 
which cause the system to behave incorrectly. Hence, 
absolute security cannot be claimed without certification. 
Consequently, In choosing among design alternatives, 
consideration has been given to facilitating tre future task 
of certification. 

1.2«2«2 The Trojan Horse Problem 

A computer system which provides sharing of user written 
procedures is susceptible to a "Trojan Horse attack" by a 
malicious user. A Trojan Horse is a procedure which 
provides a potentially useful function to attract use by a 
person having access privileges not possessed by the author 
of the procedure. The Trojan Horse program detects such use 
and performs unauthorized or unwanted functions which would 
allow the author of the procedure to obtain information to 
which he did net otherwise have access or to perform acts of 
sabotage which would not otherwise be possible. 

A general solution to the Trojan Horse problem is excluded 
from the scope of the Design Analysis. However, reducing 
the information paths between usens of diffenent clearance 
levels is within the scope of the Design Analysis. The 
issue of sabotage from a Tnojar Horse is accepted with a low 
expectation of occurrence since all users of tre system will 






be cleared and assumed trustworthy. An act of sabotage at 
the AFOSC installation Mill have considerably less severe 
consequences than at certain other military sites such as 
those having a command and control environment. 



1.2.2.3 High-Water Hark 



The design extension of having users start work at a low 
level with automatic or requested upgrade to a higher level 
as more sensitive data is needed was specifically excluded 
from the scope of the Design Analysis. This extension is 
commonly described as a "high-water mark" capability. 



1.2.2.*» Program Trustworthiness 



The ability to reduce the system recognized clearance of a 
user who may attempt to access sensitive materlalt based on 
the clearance level of procedures executeo in a user's 
process, Is commonly described as the "trustworthiness" 
capability. This is one means to reduce the potential 
damage by a Trojan Horse attempting to perform sabotage. 
The "trustworthiness" capability is specifically excluded 
from the scope of the (Design Analysis. 



1«2.2«5 Hardware Modifications 



Modifications to the hardware of the Honeywell Model 6180 
system and its peripheral devices were specifically excluded 
from the scope of the Design Analysis. No hardware 
modifications are in fact required. 



1.2.3 End Product of the Design Analysis 

This document is the end proouct of the Oeslgn Analysis. It 
describes the requirements for operating a Hul tics system in 
a restricted multi-level security mode for Secret and Top 
Secret users working In a closed secure environment. 

The requirements are translated Into a functional design of 
modifications to the Multics system needed to provide this 
restricted multi-level security operation. 

In addition, the user limitations and potential 
operat lona I /administrative problems internal and extennal to 
the system are outlined. 






This document is expected to be the basis of the proposal 
for the implementation phase of the security controls as 
described in CORL Item A010 of Air Force/Honeywell contract 
number F19628-73-D-0Q87. 






2. APPLICABLE (DOCUMENTS 



2.1 Air Force/Honeywel I contract number F19628-73-0-0087 

This contract provides the authority for the Security Design 
Analysis. The documentation requirements for the final 
report and the allowed devistions from the format are 
specified in this contract. The AFOSC Multics RFP Not 
Fl9628-73-R-002^ is included in the contract. Annex 5-1 of 
that RFP defines the primary requirements for Multics 
security controls. 

2.2 OoO 5200. 1-R Information Security Program Regulation 

Describes the military security system and the 
responsibilities of personnel who fall within its 
Jurisdiction. 

2.3 AFR 205-1 Information Security Program (USAF) 
Implements OoO 5200. 1-R 

2.** OoO 5200.28 Department of Oefense Oirectlve, Security 
Requirements for Automatic Oata Processing (AOP) Systems 

Oefines the security requirements for processing classified 
data on an AOP system (See 2.5). 

2.5 OoO 5200. 28-M Manual of Techniques and Procedures for 
Implementing. Deactivating, Testing, and Evaluating - Secure 
Resource Sharing AOP Systems. 

This Is the manual which outlines the details cf the general 
requirements specified in DoD 5200«28. 

OoO 5200.28 and OoO 5200-28-M were not identified as 

mandatory documents to be followed for the Multics system et 

the time the AFOSC RFP was issued. However, the 

requirements have been met as closely as possible in 

designing the Multics Security Controls described in 
Section 3. 






2.6 MIL-ST0-<+83 Appendix VI Para 60, "Computer Program 
Configuration Item Specification" 

Air Force suggested documentet ion format specification fcr 
the final report of the Design Analysis. 

This standard has been followed for content and general 
order of presentation. Deviations from the strict format of 
the CPCI specification were suthorized by the contract 
(Paragraph 2.1). Section 3 of the standard has been 
expanded in this document to provide a form of presentation 
better suited to the material. 

2.7 Honeywell Multics document at ior 

The following documents are mentioned here as a source cf 
background information concerning the Multics system. 

Multics Programmers* Manual 

Introduction (AG90) 

Reference Guide (AG9U 

Commands and Active Functions (AG92) 

Subroutines (AG93) 

Subsystem Writer's Guide <AK92> 
Project Administrator's Manual <AK5l> 
System Administrator's Manual (AK50) 
PL/I Language Manual (AG9<+) 
Multics Virtual Memory <AG95) 
The Multics System (AK27» 

The order numbers given above (e.g. AG90) should be 
specified when ordering these cocuments from Honeywell. 



2.8 General references 

The following documents are mentioned here as a source of 
background information concerning computer security and, in 
particular, military computer security; 

Multics Evaluation, J. P. Anderson, ESO- TR-73-276, 
Electronic Systems Division (AFSC), L. G. Hanscom 
Field, Bedford, MA, October 1973. 

Design and Certification Approach: Secure 
Communications Processor, P. S. Tasker and D. E. Bell, 
MTR-2^36, The MITRE Corporation, Bedford, MA. 
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Secure Computer Systems! Mathematical Foundations* D. 
E. Bell and L. J. LaPadula* ESO-TR-73-278, Vol I, 
Electronic Systems Division (AFSCI, L. G. Hanscom 
Field, Bedford, HA, November 1973* 

Computer Secure Research and Oevel opment Requirements, 
S. B. Llpner, MTP-H»2, The MITRE Corporation, Bedford, 
MA, February 1973. 

Preliminary Notes on the Design of Secure Military 
Computer Systems, R. R. Schell, P. J. Oowney, and G. J. 
Popek, MCI-73-1, Electronic Systems Oivlsion (AFSC) , L. 
G. Hanscom Field, Bedford, MA, January 1973. 

Concept of Operation for Handling I/O in a Secure 
Computer at the Air Force Data Services Center (AFDSC), 
E. L. 8urke, ESO-TR-7^-113 , L. G. Hanscom Field, 
Bedford, MA, October 1973. 
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SECURITY REQUIREMENTS FOR AIR FORCE DATA SERVICES CENTER 



The Air Force Data Services Center has a requirement to 
provide AOP resources and services for the processing cf 
unclassified through Top Secret data to support Headquarters 
USAF and the Office of the Secretary of the Oeoartment of 
Defense. In providing this capability. the AFOSC is 
responsible for the security of the classified data 
processed on their computer systems. 

Most contemporary shared computer systems are not secure 
because security was not a mandatory requirement of the 
initial hardware and software design. The military has 
achieved reasonably effective physical. communication, and 
personnel security. Hence, the primary computer security 
problem is that of information access controls in the 
operating system and supporting hardware. Essentially, an 
effective means for enforcing very simple protection 
relationships (e.g. user clearance level must be greater 
than or equal to the classification level of accessed 
Information) is needed? however, solutions to some of the 
more complex protection problems such as mutually suspicious 
processes are not required. 

In current practice at AFDSC, computer security is achieved 
by dedicating- an entire computer system to users clearec to 
a particular security level. This approach results in poor 
utilization of computer resources, and hence, high costs for 
data processing. 

Providing a two-level security operating mode on the 
Honeywell 6180 Multlcs System nil! be the first step toward 
fully utilizing the resources of a single computer system 
serving a user community with mu I tl p I e- I eve I security 
requirements. 

The decision to design and implement a two-level security 
system for the Air Force Data Services Center is predicated 
on our capability to provide those security controls that 
will reduce the rlsK of release of Too Secret information to 
Secret users to an acceptable level. No claim is being mace 
as to the ability of the security system to withstand 
penetration attempts. The approval test that the system 
will be subjected to prior to its installation will only 
demonstrate the exlstance of security controls. It is 
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anticipated that the efforts to augment the security of the 
Multlcs System combined with the limitation imposed on the 
operation of the system within the AFOSC controlled 
environment will proviae ar operationally acceptable 
assessment of risk. 
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3.1 System Operating Environment Definition 



3.1.1 Hardware/Software Interface 

The central processing unit used is the Honeywell Model 
6180. The operating system is Multics, with such 
modifications and extensions as result from this Security 
Oesign Analysis and the systetr programming task that will 
fol low. 

A full description of the Honeywell 6180 hardware and the 
Multics software is beyond the scope of this cocument. The 
interested reader is referred to the publications listed in 
Section 2.7 for such detailed descriptions. 



3.1.2 User Interface 

The user interface is the appearance the system presents to 
the user. To the greatest degree possible, this appesrance 
will remain the same as current Multics. 

Functions available to the user will be identical to current 
Multics where feasible, and ecuivalent in most other cases. 

3.1.3 Definition of AFDSC Controlled Environment 

The central computer facility will be a Top Secret 
control led area. 

All remote terminal areas will be physically protectee to 
the Top Secret level even though they may be used as Secret 
controlled areas. 

The communications between the central computer facility and 
all remote terminal areas will be via Top Secret encrypted 
data I ines. 

Top secret clearances will be required for all persons 
(operators, system programmers, system maintenance 
personnel, field engineers and others) who need physical 
access to the central computer facility; or any hardware. 
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data lines or terminal connections in the remote terminal 
areas; or data and control lines between the central 
computer facility and the remote terminal areas. 

All programmers, analysts, users or persons who are 
registered to use the Multics system at AFOSC will have 
either a Secret or a Top Secret clearance. 

All I/O operations will be performed by central site 
operating personnel. No user will be permittee to mcunt his 
own tapes, disks or other media. 



3.1.*f Definitions 
access 

The ability and the means tc approach, communicate with 
<input to or receive output from), or otherwise make use cf 
any material or component in an AOP System. 

In the military security system, a person *ay be granted 
access to an object only if his clearance level is greater 
than or equal to the classification level of the object; 
his clearance category set contains all categories in the 
category set of the object; and he has the proper "neeo to 
know" in reference to the object. 



AOP (Automatic Oata Processing) 

An assembly of computer equipment, facilities, personrel, 
software and procedures configured for the purpose of 
classifying, sorting, calculating, computing, summarizinc, 
storing, and retrieving data and information with a minimum 
of human intervention. 



anonymous user 

An anonymous user is an unregistered user of the Multics 
system whose oersonid (see belcw) is "anonymous"; in other 
words, his personid is unknown to the system. An anonymous 
user may or may not be required to furnish a password in 
order to gain access to the system. 



branch 



A branch is a component of a directory which describes an 
immediately inferior segment or directory. 
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interprocess communication (ipc) 

Interprocess communication is a facility which allows one 
process to communicate with another in a controlled manner. 
Both the sending and receiving processes must adhere to a 
specified protocol. 



"level 



This term is used frequently as an abbreviation for th« 
level/category combination which describes a clearance or < 
classification. Thus the "level" of a process is th< 
clearance of the process and the "lever* of a segment is th< 

rl ae^f f i rat inn r\ 4 ♦ K a conmant . 



Multi-Level Security Mode (see also Two-Level Security Mode) 

A mode of operating under an operating system (supervisor or 
executive program) which provices a capability permitting 
various levels and categories cr compartments of material to 
be concurrently stored and processed in an AOP System. In a 
remotely accessed resource-sharing system, the material can 
be selectively accessed ano manipulated from termirals by 
personnel having different security clearances and access 
approvals. This mode of operation can accommodate tt-e 
concurrent processing and storage of (a) two or more levels 
of classified data, or (b) one or more levels of classified 
data with unclassified data cependlng upon the constraints 
placed on the systems by the Designated Approving Authority. 

Operating System (0/S) 

An integrated collection of service routines for supervising 
the sequencing and processing of orograms by a computer. 
Operating systems control the allocation of resources to 
users and their programs and play a central role in assuring 
the secure operation of a computer system. Operating 
systems may perform debugging, input -output , accounting* 
resource allocation, compi lati en, storage assignment tasks, 
and other system related functions (Synonymous with Monitor, 
Executive, Control Program, anc Supervisor). 



personid 

The registered name cf someone who Is authorl2ed to use the 
system. It is usually constructed from the last rame 
(surname) of the person. 
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process 



A process Is the active agent of the user on Multlcs and (in 
the security systeml has a clearance which iray not exceed 
the user's clearance. The lifetime of a process normally 
corresponds to a user's terminal session anc is described 
internally by an address space and a point of execution. 
Both the address space and the execution point are dynamic 
over the life of the process. 



proj ect id 

The registered name of a project which has an account on the 
system. 

Remotely Accessed Resource-Sharing Computer System 

A computer system which includes one or more central 
processing unitst peripheral aevicest remote terminalst and 
communications equipment or interconnection links, which 
allocates its resources to one or more users, and which can 
be entered from terminals located outside the central 
computer facility. 



segment 

A segment Is a logical unit of storage on Hultics. It 
roughly corresoonds to a file stored on a disk pack and 
accessible to a user. The segment is the smallest element 
of supervisor access control in the Multics storage system. 



Two-Level Security Mode 

A mode of operating a computer system which provides a 
capabi lity permitting Top Secret and Secret data to be 
concurrently stored and processed in an AOP Svstem. This 
mode is more restricted th3n the multi-level security mooe 
in that only Top Secret ano Secret cleared users will be 
permitted to access the system. No unsecure terminals will 
be connected to the system. Software, hardware, 
administrative, and physical controls will provide the 
safeguards to assure the integrity of the classified oata 
processed. 
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user 



An Instance of a person logged Into the system on a project, 
A user is Identified by a userld. 



userld 



A table entry which would describe a user (e.c. an access 
control list entry). A userld consists of 
"person id. pro J ectid. tag." where tag Is normally "a" for an 
interactive user, "m" for an absentee user, and "z" for 
certain system daemons. The userld is also called the 
"principal identifier" or "group_ld" of the user. 
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3.2 APPLICATION OF SECURITY CONTROLS TO MULTICS 



Each person registered on Multlcs Is known to the system by 
his name (personld) and has a password to authenticate his 
identity. The authent lcat ior data for a personid must 
include the person's system-recognized clearance. 

Each user of Multics, as identified by his userld 
(person-project combination)* is associated with a Multics 
process. Each Multics process must have a clearance which 
is equal to or less than the clearance of the person 
associated with the process and must remain constant for the 
life of the process. 

Access control is generally described as a subject 
attempting to access an object through an intervening 
reference monitor. The referenc€ monitor checks, each and 
every time a subject attempts to access an object, to see if 
the subject has the proper authorization to perform the 
desired operation (e.g. read» write, execute, append, 
modify, delete). In Multics, a process is the only subject 
which can make a reference to any object. The set of 
objects are segments, directories, branches, I/O channels 
and interprocess communication messages. Each object must 
have a classification level ano category set associated with 
it. 

In Multics, the reference monitor which valioates each 
reference to an object is the "ring 0" supervisor in 
conjunction with processor hardware protection mechanisms. 
Within the protection ring scheme supported by the Honeywell 
6180 processor, ring Q is the most privileged and most 
protected ring of operation. All access control decisions 
are made within ring 0. Each tiire a process attempts to 
gain access to an object, the clearance of the process is 
compared with the classification of the object and access Is 
either granted or denied in accordance with rules designed 
to emulate the military security system. In aadltlon to 
classification, certain objects such as segments and 
directories have an associated access control list which 
specifies persons having need to know authorization as In 
the military security system. 
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When the classification of two objects is compared, four 
relationships are possible! 

less than 

equal 

greater than 

isolated 

The classification of object i is considered "less than" the 
classification of object 2 if* 

1. The level of object l is numerically less than or 
equal to the level of object Z\ and 

2. The category set of object 1 is a subset of the 
category set of object 2; and 

3. The classification of object l is not equal to the 
classification of object 2. 

The classifications of two objects are considered "equal" 
if* 

1. The levels are numerically equal* and 

2. The category sets are identical. 

The classification of object l is considered "greater than" 
the classification of object 2 if* 

1. The level of object i is numerically greater than 
or equal to the level of oblect 2S and 

2. The category set of object 2 is a subset of the 
category set of object 1» and 

3. The classification of object l is not equal to the 
classification of object 2. 

The classifications of two objects are considered "isolated" 
if the category sets are isolated. 

The "minimum" of several classifications Is defined as* 

1. The numerical minimum of the levels; and 

2. The intersection of the category sets. 

In order for a person to access information, the irllitary 
security system requires that the clearance of the person be 
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greater than or equal to the classification of the 
information. A sufficient condition for satisfying this 
requirement within the computer system environment is the 
enforcement of the following two rules! 

1. A process having clearance £ may not "reed up*" i.e. 
read an object having a classification greater than q. 

2. A process having clearance n m ay not "write down*" i.e. 
write an object having a classification less than o« 

With these two rules enforced* it is impossible for any 
process to extract information from an object of higher 
classification or to transfer information from an object of 
higher classification to an object of lower classification. 
Hence* no compromise of classified informatior can occur. 
This principle is known as the "fixed level property." A 
further restriction Is also desirable which forbids a 
process to write in an object of higher classification 
whenever writing can be used to destroy information. In 
order to provide some protection against sabotage* "write 
up" operations must not be permitted for such objects as 
segments* directories* and branches. 

It is Important to recognize that the rules described above 
represent a sufficient* but not a necessary condition for 
achieving security. Although the fixed level property 
restrictions wU I be strictly enforced for all user 
processes, they will, in certain circumstances* be applied 
Interpretlvel y for trusted system processes. In no 
circumstances* however* will security be violated* because 
trusted system processes mU5t operate correctly. 

The individual user must be able to specify which users 
should have "need to know" for a given segment or directory 
by use of the Access Control List. The mode of access (e.c. 
read* write) allowed to a process by the current Multlcs 
Access Control List must be further restricted to ensure 
compliance with the fixed level property rules. In other 
words* the fixed level property rules must take precedence 
over the Access Control List. 

Information transmitted between hardware modules must be 
carefully controlled by the system and no user shoulo be 
able to directly affect the action of an active irodule 
(except for the CPU). Furthermore* no user process should 
be able to execute any programs which would perform external 
I/O to any device other than his terminal. 



The system can be logically divided into two environments! 
internal and external. The Internal environment Is totally 
controlled by the system. This Includes! processors* 
memory* disk drives* I/O multiplexers* bulk store* 
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communication processors* and face drives usee for system 
functions. ' 

The external environment can be directly influenced by the 
actions of a process. This environment induces: 
terminals* line printers* card readers* card punches* 
non-system tape drives* and other devices In the I/O class 
not used for system functions. 

To provide a "secure" pipeline between the internal and 
external environments* a trusted process must perform the 
actual information transfer on behalf of the user. This 
will further ensure that failures or "software bugs" will 
not be exploited by a user. The terminal must be the only 
exception to this rule and this exception is only made for 
the sake of efficiency. 

Whenever possible* new or mocified operator interfaces 
supplied with the security control features will be designed 
to provide extra aids or simplicity in structure to helD the 
operator avoid mistakes which could become security 
viol at ions. 

Security and administrative functions should be separated to 
ensure that the System Administrator will not make 
security-related decisions and to avoid burdening the 
Security Officer with purely acm in istrat ive decisions. 

The security controls must be designed so that* the system 
is easy to use? the users are encouraged to croperly 
classify data (rather than over-classify)? the least 
possible amount of current Multics functionality is 
sacrificed? and the current user interface is mairtained 
wherever possible. 

All high-level security-related actions performed within the 
system should oe audited to ensure user responsibility and 
to provide early warning of any subversion attempts* misuse 
of the security controls* or actions which could lead to 
compromise. 

All revisions to the system must be carefully checked to 
minimize the possibility of "bug fixes" or new "features" 
causing the system to behave incorrectly* especially insofar 
as security is concerned. 
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3.3 PROCESS CLEARANCE ASSIGNMENT 



3-3.1 Requirements 

A Mul tics process is uniquely associated with a person who 
is registered to use the system and a project to which that 
person may charge his system exoenses. 

When a process is created for a user, a clearance will be 
established for the process. This clearance must not be 
changeable by request for the life of the process. It is 
the process clearance which will be used to determine a 
user's authorization to access classified information In the 
system. 

To provide a degree of flexibility and aominlstratlve 
control, the clearances of several entities must be stored 
on the system. 

The data associated with a personid (the system unique 
identification for the person) must contain the clearance of 
the person. Similar clearance data must be associated with 
each Drolectid. In addition, the data which describes the 
limitations of a person on a given project must have 
clearance data. 

The clearance to be assigned to a process must be determined 
as followsJ 

1. No process will be createc for a given userld, i.e. a 
given person on a given project, with a higher 
clearance than the minimum of the person's clearance, 
the project's clearance, and the person's clearance 
within the project. 

2. No user should be able to create a process with a 
higher clearance than the maximum clearance of his 
terminal • 

3. A user must be able to request a process with a lower 
clearance than the rririirum of his userlo and terminal^ 
cl earance. 

<♦. A user must be able to specify a oefault login 
clearance (no higher than his personid clearance). 
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Only the System Security Officer (SSO) must be able to 
assign clearances for a personid or a projectid. If the SSO 
lowers the clearance of a personidt the user's process must 
be forceably terminated if he has an active process with a 
clearance greater than the downgraded clearance of the 
personid. 

Each user must be told his process clearance at the 
beginning and normal termination of the process. In this 
way, the user is made explicitly aware of his level of 
operation. Hence, mistakes such as placing Top Secret 
information in a Secret file are unlikely to occur, and if 
they do occur, are likely to be cetected before any harm can 
result. 

By use of a command, each user should be able to request 
that the clearance of his current process be typed on his 
terminal . 

The names associated with a "level'* should be set by the 
insta I I at ion. 



3.3.2 Oesign Approach 

The system control process uses three tables to verify that 
a user should be logged in. 

1. The Person Name Table (PNT) contains an entry for each 
personid on the system. 

2. The System Administration Table (SAT) contains an entry 
for each projectid on the system. 

3. The Project Definition Table for the users project 
(Prol.pdt) contains an entry for each personid allowed 
to used the project. There is one project definition 
tablt? for each projectid. 

Each of these tables will be modified to hold clearance 
level and category set data for each entry. The system 
control process will check this clearance data to determine 
the maximum clearance for a userid. 

A new table, called the Peripheral Control Table (PCT), will 
be used by the system control process to check the maximum 
clearance of the terminal being used by a person attempting 
to log in. Since terminals will be "hard wired" to the 
system at AFOSC, each terminal can be uniquely Identified by 
an associated channel number.. In the genersl case, there 
may be crypto-dia I -up terminals. However, in that case, the 
crypto units will provide the unique terminal 
identification. As an extra check, the answerback cooe 
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received from a terminal Mill be compared against its 
"registered™ answerback code. This answerback test will be 
useful in detecting mistakes* as well as malicious 
tampering, involving communications lines and terminals. 

At login time* the user will be given a process with a 
clearance no higher than the minimum of the clearances from 
the PNT, SAT, ProJ.pdt, ano the PCT . . The default login 
clearance for each user will initially be the lowest 
possible clearance* i.e. unclassified. A new login option 
will be supplied to permit a user to change this default. 
Also, another new login option will be provided which allows 
the user to specify a particular clearance for a given 
-login. 

An attempted login may be rejected for the following 
reasons t 

1. illegal login word 

2. incorrect personid or projectid 

3. incorrect password 

*♦• incorrect level option 
5. unrecognized login option 



These 
purpose 



rejected login attempts will be recorded for audit 
„_. ,-^-s. In addition* if a user attempts to use s terminal 
with a maximum clearance greater than the personid clearance 
from the PNT, a message will be sent to the operator, since 
this will indicate a breach of physical security. The 
clearance of the process will be stored in the process 
initialization table (pit) and in the ring process data 
segment (pds) of the process to ensure tnat it is 
"M orgeab le for the life of the process. 



s 
un 



The Project Administrator Mill be able to specify for a user 
on his project a lower maximum clearance than authorized in 
the PNT ana SAT, if this ability is granted by the SSO. 




Anonymous users should not normally be permitted on the 
system since password authentication is not always required 
for them. Where passwords are required for anonymous users, 
these passwords are controlled by project administrators 
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rather than the SA or the SSO. If, at any time* anonymous 
users are permitted on the system* they nil I always be given 
unclassified processes* 

Absentee processes will be- created at the level of the 
requesting process unless an option is specified. A user 
will not be able to create an absentee process with a 
clearance which is lower than, his current process clearance* 
since the passing of arguments to the absentee process would 
constitute a write-down operation. 

A new_proc option will be added to allow a user to 
upgrade/downgrade his level of operation. When no option is 
specified, the default level for the new process will be the 
current level. (The same will be true for abnormal 
termination of a process). 

The system process_overseer_ procedure will identify the 
"level" of a process created for a user by printing the 
"level" name on his terminal. (This cannot oe oefeeted.). 
The same message will be printed by terminate_process_ for 
normal process termination. 

Installation parameters will be used to store the character 

strings used to identify each classification level and 

category. The system assumes that the names used for levels 
and categories are unc I ass if iec. 

Each user will be able to execute a command which will print 
the "level" of his process on his terminal based on the oata 
In the "pit." 

3.3.3 Potential Security Problems 

The following areas will become security problems only if 
the non-malicious user assumption of Section 3.1. «♦ is 
viol ated. 



wci r easily, vjvji mc um y nieans for compromise would be 
through the quota path on directories which has a very low 
transmission rate. (See Section 3.7. *♦) 

By providing a means for a user to change his "level" of 
operation through program control (new_proc with level 
option), a Trojan Horse coulo set itself up ss the program 
to be called when a user attempts to change to a new "level" 
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process. An elaborate Trojan Horse could totally simulate 
system action for hew_proc to fool the user Into thinking he 
Is operating at a higher level. Now If the user attempts to 
input classified data, the Trojan Horse could, by simulating 
the entire, user interface, cause the user to put the 
classified data into a segment with a lower classification 
This problem can be solved by only allowing a user to 
"new_proc" to the same or lower "level." 

In a similar manner, a user may write his own "logout -hold" 
command to fool the next user of the terminal into thinking 
he is talking to the system instead of the previous user's 
process. This could allow a malicious user to capture the 
password of another user, thus permitting sabotage and need 
to know violations. (See Section 3.k.±.) Also, the user 

environment simulation described above could be useo here. 
The solution to this problem is to require the terminal to 
be powered off by each user before attempting to login. 
(This can be handled several ways. The choice is up to the 
site manager.) 

Solutions exist to all of the above potential problems. 
However, given the low expectation of occurrence of these 
problems, the required sacrifices in user convenience were 
felt to be unwarranted within the assumed benign 
environment. 
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3.1* PASSWORD CONTROL 



3.*»«1 Description 

The Multlcs access control mechanism depends on several 
Important factors. First ana foremost is the notion of an 
unforgeable "user name" which identifies the access rights 
of a Multlcs process! the entity which performs all tasks on 
behalf of the human user. A Multlcs "user name" is called a 
principal identifier* and consists of three comconer.ts t 
Person, Project, and Tag. The Person component uniquely 
Identifies a registered user of Multlcs. The Project 
component Identifies a registered project, and Tag Is 
presently derived from the type of process (i.e. 
interactive, absentee, or consoleless daemon). 

In order for Multlcs to successfully enforce access 
controls, it must be possible tc uniquely and positively 
Identify each user at login. This is presently accomplished 
by assigning each registered person his own password, anc st 
each login, requesting his password for verification 
purposes. If the password stored by Multlcs matcf-es the 
password given by the user, Multlcs assumes the user is 
valid, and creates a process with the principal identifier 
(userid) of the user. If, after giving the user several 
chances (to allow for typing mistakes), a correct psssword 
has not been received, Multlcs refuses the login. 




luwaei i ue dUlc iu luy All da n« uinei usci • a i 31 uui t uc 

noted, however, that due to physical security controls at 
AFDSC, the compromise of a password cannot result in the 
compromise of classified Irformatlon. A person who learns 
another person's password will not be able to log in with 
the same clearance as the owner of the passworo unless he, 
himself, has an equal or higher clearance which affords him 
access to a terminal of equal or higher c I assi f icatior. 
Therefore, password compromise can, at worst, result In 
sabotage or need to knew violations. 



e 
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3.^.2 Requirements 

The present "work factor" needed to guess a person's 
password Is not high enough, due to the ability of a user to 
choose his own password. Therefore, It Is a requirement 
that the system assign passworcs. (The passwords could have 
been distributed manually, but that was felt to be too 
burdensome for the system administrator.) 

To provide the ability to control the "age" of a password 
(how long it has been in use by a user), it is a requirement 
that the system be able to force a user tc change his 
password at pre-deteritlned intervals. 

To be able to recover from a password breach, it is a 
requirement that the System Security Officer be able to 
force some or all users to change their oasswords. 



3.<*.3 Design Considerations 

Since all users must go through the login ritual, every 
attempt will be made to "human engineer" this area of the 
system. The passwords generated by the system will be 
designed to be pronounceable and therefore, easy to 
remember. 



3.U.U Chosen Approach 

After the identity of the user has been authenticated by the 
login procedure, the system will warn the user if it is time 
to change his password. To force the user to change his 
passwora within an insta I I at ior-parameter grace time, the 
user will be locK.ec out if he exceeds the grace time. To 
properly handle persons who logic infrequently, the grace 
"time" will actually be implemented as a grace number of 
logins. 

The system generated passwords will be baseo on English 

digraph frequencies since such words are more pronounceable, 

and thus more easily remembered, than ranoom strings of 
characters. 

Since passwords must be treated as classified information, 
the system will prefix the printing of a new password with 
the label "confidential." 

To ensure that the user understands the new password and 
that it was printed correctly, the user will be requireo to 
echo it at login time. 
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The SSO will be able to set the Interval at which users must 
change their passwords. 

The SSO will be able to force a user to change his passworo. 

Incorrect login attempts will be audited (see Section 3.16). 



3.^.5 Examples 

1* login Whitmore -charge_oass word 

2 Password! 

3* 

<♦ Con f ldentlal t New psssword is "abcodo." 

5 New Passwordt 

6* 

7 Passworo changed. 

Lines marked with "♦" are typed in by the user. The 
terminal does not print passwords tyoed by the user. 

In the first example, Whit more requests that his passworo oe 
changed. The system requests his current oassword and 
assigns him a new one. The user is requested to enter his 
new password for verification. If both passwords were typed 
correctly, he will be logged in and his password will be 
changed within the system. If either password was 
incorrect* the entire login would be incorrect ana the user 
would have to try again. 

1* I ogln Whitmore 

2 Password* 

3* 

<♦ You must change your oassword within 3 logins 

In the second example, Whitmcre is notified tt~at his 
password must be changed within the next three logins. If 
he falls to change his password, he will be locKed out. The 
user may login, even if he has been locked out, by changing 
his password. 
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3.5 INFORMATION CHANNELS BETWEEN PROCFSSES 



The fixed level property rules defined in Section 3.2 are 
designed to restrict the passing of information between 
processes. These restrictions must be applied to all 
information channels, i.e. to all mechanisms withir the 
system which enable processes to exchange inforirat ion. 
Certain mechanisms such as shared segments and the 
interprocess communication facility are deliberately 
provided to serve as information channels. Other mechanisms 
such as segment names and access control lists are intenaed 
to serve different purposes, but could be misused as 
information channels by processes attempting to compromise 
information. Hence, all information channels must be 
identified and, where necessary, additional access checking 
must be provided in order tc enforce the fixed level 
property rules. 



3.5.1 Segment Sharing 

A shared segment is the most natural channel for two 
processes to exchange information. For a process with a 
clearance P, the system will systematically remove the 
"write" permission on any segment whose classification is 
lower than P, and all permissions on any segment whose 
classification is higher th3n P. It is therefore impossible 
for a process to "write down" or to "read up." 

More detail can be found in section 3.6 - "Access to 
Segments." 



3.5.2 Directories 

Directories ara another channel through which processes can 
exchange information. Each data item contained in a 
directory is assigned a specific classification (as 
described in Section 3.7). Ring primitives in charge of 
manipulating directories will provide additional checking by 
which they will systematically refuse to perform a request 
If it would result in a "write down" or a "read up." 
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Unfortunately* however* a number of directory items such as 
quota used. date-time modified* and date-time used are 
changed not by explicit request* but rather as a side-effect 
of some action performed outside the directory. For 
example, the quota usee count stored in a directory can be 
increased by growing the size of an inferior segment. 
Information channels of this type present rather unusual 
problems. Solutions to these problems as well as other 
details of directory access control are discussed in "3.7 
Access to Directories.** 

3.5.3 Interprocess Communication 

Using the Interprocess Communication (IPC) facility* a 
process can send a 72-bit message to another process. The 
IPC facility will provide additional checking by which it 
will systematically refuse to send a message that would 
result in a "send down.** **Seno up" will be permitted for 
IPC since this is not a means of sabotage. The enforcement 
of the security will be done in ring 0. 



3.5.^ Message Segments 

In the current Mul tics System, message segments are ring ore 
segments* manipulated by a rirg one module called the 
Message Segment Facility (msf). The Implementation of the 
msf is such that a process needs the "read" and the "write" 
capabilities in ring one on a message segment In order to be 
able to put a message in it or tc extract a message from it. 
It follows that, if the msf is used withir the security 
controls* communication between processes through message 
segments will be restricted to processes of identicial 
clearance. Tnis restriction has been accepted. 

As far as security is concerneo* message segments will be 
treated the same as any other segment by the ring 
supervisor and one can repeat what was said for segments in 
general: no read up cr write oown on a message segment will 
be permitted in a user process. However some system 
processes* in some special cases and in a controlled manner* 
will have to bypass the fixed level property restrictions on 
message segments. However, in no circumstances will 
security be violated. 

In the current Mul tics system, all user processes tha* 
request a service from a system process send their request 
through a message segment. It fellows that, wherever the 
current system uses one message segment to Queue user 
requests for a system process, it will be necessary to 
provide one message segment for each existing 
c I asslf icatlon. 
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An alternative approach would have allowed security rules to 
be enforced in ring one rather than ring 0. In this scheme, 
ring would grant read ana write access for message 
segments to processes of all clearances. Each individual 
message stored in a message segment would be "classified" by 
the msf at the clearance level of the sending crocess. The 
msf would only permit extraction of a message by a process 
having a clearance higher or equal to the classification of 
the message. However, this would bring the msf plus all 
other ring one procedures within the security perimeter, 
thereby making the task of certification more difficult. 



3.5.5 Summary 



It is important to understand that of the several 
information channels described above, shared segments are 
the only channel through which classified information would 
routinely be stored and passed. IPC messages and directory 
items such as segment names or access control lists would 
not normally be used to transmit or store classified dcta. 
(All segment names are assumed to be unclassified so that 
they may appear in unclassified accountability forms for 
printed output. See Section 3.1Q.» Hence, from a practical 
standpoint, the assigning of correct classifications to 
segments by users and the addition of fixed level proDerty 
access checking for segments is sufficient to prevent a 
single malicious user from directly compromising classified 
information. 

The other information channels do not become a serious 
problem until one considers the possibility of two (or more) 
processes cooperating in an effort to compromise 
information. This cooperation could take one of two forms. 
Finst, two malicious users might dinectly consoine to 
compromise information. Second, a nonmalicious user might 
unknowingly employ a Trojan Horse Drogram suDDlied by a 
malicious user. (See Section 1.2.2.2.) The case of two 
users conspiring to compromise irformatlon is actually more 
of a "people" problem than a computer system problem. Even 
if no effort were made to secure those Information channels 
not normally used to store or transmit classified data, 
conspiring users would probably still find it easier to pass 
information outside the system. Therefore, the Trojan Horse 
attack is really the only f crm of attack for which 
information channels other thar segments are essential. 

The design presented in this report is directed to 
eliminating all read-up ano write-down information channels. 
The elimination of all known read-up channels Drohibits a 
malicious user from directly accessing classified 
information which he is not legitimately cleared to see. 
Hence, a malicious user must resort to "setting a trap," 
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i.e. he must create a Trojan Horse program with the hope 
that an unsuspecting user having a higher clearance will 
call it. Although a general solution to the Trojan Horse 
problem is beyond the scope of this design* the e lircinatlcn 
of write-down channels can considerably reduce the threat 
represented by the Trojan Horse form of attacK A 
write-down channel is the only means by which a Trojan Horse 
program can actually compromise information. Therefore* the 
elimination of all write-down channels can effectively 
prevent compromise, although sabotage and neeo to knew 
violations would still be possible. With one exception, all 
explicit write-jown channels within the Multics systerc have 
been eliminated In this deslcn. The quota used channel is 
the single exception. Not only does this channel have a 
very low transfer rate, but also, any significant use of 
this channel can be easily detected through auditing. (See 
Section 3.7.3 for details.) 
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3.fc ACCESS TO SEGMENTS 



3«6.l Requirements 

Every segment must have a classification de fired by a level 
and category set. This classification applies to all oata 
contained within the segment. 

For each segment there mcst exist a list of persons raving 
need to know access to the contents of the segment. 

The sharing of segments among processes must be controlled 
so as not to violate the fixed level property rules. 

3.6.2 Design 

The classification. I.e. level and category set, of a 
segment will be permanently recorded In its branch. For 
reasons explained in Section 3» 7» the classification of a 
segment must equal the classification of its oarent 
directory. This lnrplles that the classification of a 
segment will always eoual the clearance of the process which 
created it, since a process can only append a branch to a 
directory if its clearance equals the directory 
c I assi f lcat ion. 

As Is already tne case in Multics, an access control list 
(ACL) will be associateo with every branch. Each ACL entry 
contains a ussrid and access mode. The access mode 
describes the types of eccess (e.g. read, execute, write) 
permitted the associated user. Hence» the ACL will be used 
to control neea to know access to a segment. 

In accordance with the fixed level property, write down and 
read up operations on segments will be prohibited. Also, in 
order to prevent sabotage, write up operations on secments 
will be prohibited. With these restrictions enforcec, 
sharing of segments among processes having different 
clearances cannot compromise infcrmation. 

The access permitted a given process to a given segment will 
be computed as follows. If the clearance of the process is 
lower than the classification of the segment, +he process 
will be given null access to the segment. If the clearance 
of the process equals the classification of the segment, the 
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process will be given whatever mcde of access* if any, is 
specified in the ACL. If the clearance of the process is 
higher than the classification of the segment, the process 
will be given the mode of access specified in the ACL minus 
write permission. 

In order to reference a segment, a process must first 
"initiate" the segment irto its address space. /it 
initiation time, the access computation described above will 
be performed to determine if the process has any access to 
the segment. If so, the segment will be adced to the 
address space of the process. Thereafter, all references to 
the segment will be valloated by the processor hardware. 
Each segment fault taken by the process on the sequent will 
force access to be recomputed by the above method. 

3.6.3 Implications 

The rules governing access to segments, while satisfying 
security requirements, have certain curious implications 
worth noting. A problem arises over the fact that for each 
user there tyolcally exists a number of corresponalog 
writeable data segments (e.g. mailboxes, console message 
segments, abbrev profiles, pirotd files). Conceptually, it 
makes little sense to segregate the functions of these 
segments according to process clearance. Nevertheless, 
these segments must be assigned a specific classification 
and hence, will be writeable by a process at one clearance 
level only. As a result, the user who operates at more than 
one clearance level must sacrifice a certain amount of 
flexibility anJ convenience in sending and receiving mail, 
creating abbreviations, updating pmotd files, etc. 
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3.7 ACCESS TO DIRECTORIES 



3,7. 1 Classification of Directory Information 



Every directory has a classification defined by a level and 
a category set. 

The classification of a directory cannot be less than the 
classification of its parent directory. This restriction is 
necessary in order to eliminate 3 write-down information 
channel using directory names. Suppose, for example, that 
an unclassified directory were permitted to exist in the 
hierarchy below a Secret directory. A Secret process could 
change the name of the Secret directory, thereby also 
changing the pathname of the unclassified directory. This 
action could, of course, be oetected by an unclassified 
process. Therefore, it is necessary that a directory ano, 
for that matter, a segment, have an equal or greater 
classification than its parent directory. This rule is 
hereafter referred to as the "ron-decreaslng classification 
rule." For reasons explained below, the c I assi f icatior of a 
segment is further restricted to be equal to that of its 
parent directory. 

As with segments, a directory will initially receive the 
same classification as its parent directory. However, a 
special "upgrade" operation will be available which permits 
a user to raise the classification of a directory. It is 
required that a directory be empty in order to be upgraoea. 
Otherwise, after upgrading, inferior segments or directories 
would stand in violation of the non-decreasing 
classification rule. If the entire subtree of a directory 
were upgraded, a potential for unwanted overcl assi f icat ion 
would exist. (Also, implementation would be difficult.) 

Several problems arise with respect to the branch of an 
upgraded directory. Since, as described so far, such a 
branch is contained in a superior directory of lower 
classification, a user having access to an upgraded 
directory would not be permitted to modify its branch. This 
restriction would be very Inconvenient In practice. 
However, a mora, serious problem is posed by the fact that a 
user having access to an upgraded directory would be able to 
implicitly modify its branch. For example, by increasing 
the size of an upgraded directory, one coUd change the 
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current length attribute In its branch. This constitutes a 
write-down information channel. 

In order to eliminate the above problems, an individual 
branch will have the same classification as the segirent or 
directory which it describes* rather than that of its 
containing directory. Only upgraded branches are actually 
affected by this new definition since non-upgraded branches 
will still have the same classification as their contairlng 
directory anyway* 




only be modified by a process 
containing directory. 



3.7.2 Explicit Operations on Directories 

Whenever the supervisor is explicitly requested to perform 
an operation on a directory, a check will be made to ensura 
that the user has the right to perform the operation 
according to the current Muftics access control rules and 
the new fixed level property rules. In particular, the 
supervisor will refuse any request that would result In a 
"read up" or a "write down"? it will also refuse all 
requests that could result in sabotage by "writing up." 

Operations that would return tc the caller any part of a 
directory having the same classification as +he directory 
Itself will be executed only if the clearance of the process 
Is equal to or higher than the classification of the 
directory. Examples of these operations Include listing a 
directory, listing tne initial ACL, and reading the auote. 

Operations that would modify any part of a directory hawing 
the same classification as the directory Itself will be 
executed only if the clearance of the process Is equal to 
the classification of the directory. Examples of these 
operations include adding or deleting entry names, changing 
the initial ACL, and creating a new branch (since a branch 
is originally created with the classification of its 
containing directory). The deletion of branches, both 
upgraded and non-upgraded, is also Included In this catecory 
since it Involves the deletion of branch names. Note, 
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segments 

Operations that would return to the caller any part of a 
branch, other than the entry names, will be executed only If 
the clearance of the process Is equal to or higher than the 
classification of the branch Itself. Examples of such 
operations Include reading the branch status, reading the 
ACL, reading the ring brackets, reading the bit court, 
reading the date-time used or moclfied. 

Finally, operations that would modify any part of a oranch 
other than the entry names will be executed only if the 
clearance of the process Is equal to the classification of 
the branch. Examples of such operations Include changing 
the ACL, changing the bit count, changing the maximum 
length, and changing the safety switch. 

The "movequota" operation is unique in the sense that it 
modifies two directories at once, one immediately inferior 
to the other. A problem arises when quota Is moved to or 
from an upgraded directory. To do this, a process is 
required to modify two directories of different 
classifications which Is normally not permitted. Since 
writing down must be prohibitec, a process at the "level" of 
an upgraded directory cannot be allowed to move quota 
between that upgraded directory and its parent directory. 
Therefore, the movement of quota to or from an upgraded 
directory will be performed only by a process at the "level" 
of the parent directory. {Modify permission on the ACL of 
both directories will still be required.) The fact that a 
lowei — level process will be able to withdraw quota from an 
upgraded directory constitutes a mild form of sabotage which 
can only temporarily impede a higher-level process, but 
cannot destroy or compromise information. This Is not felt 
to be a serious problem since this could be audltable ard 
quota can easily be restoreo. The alternative of not 
allowing quota to be withdrawn from an upgraded directory 
except by special action of the SSO Is considerably less 
attractive. 

The new upgrade operation for directories is also rather 
unique. Since it involves modifying an element of a branch, 
it can only be performed by a process at the same "level" as 
the branch. In addition, the directory to be upgraded must 
be empty as mentioned above, furthermore, for reasons to be 
explained shortly, the directory to be upgraded must have a 
terminal quota. 
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3.7.3 Implicit Operations on Directories 

As described above, addit local access checking can be 
performed for all explicitly requested directory operations 
so as to comply with the fixed level property rules. 
Unfortunately, however, there exists a class of implicit 
directory operations which present a more difficult problem. 
An implicit directory operator Is basically a side-effect 
of some action performed outside the directory. One such 
operation, the changing of the current length attributet has 
already been discussed. Three other implicit directory 
operations, which are the changing of quota used, dcte-time 
used (dtu), and date-time modified (dtm), still csusa 
problems within the directory access scheme dascribec thus 
far. These oroblems are discussed below. 



3.7.3.1 The Quota Used Problem 

Changing the number of pages usee by a segment or directory 
causes the "quota used" number to be incremented or 
decremented In all superior directories up to and inducing 
the nearest superior directory having a terminal auota. If 
this chain of superior Directories Includes one or irore 
directories of a lower c I ass if cat ion than the segment on 
directory being modified, then a write-down Infcnmatlcn 
channel exists. Thene ane three methods of penfonirlng 
write-down operations on this information channel: 1) 
changing the number of pages usee by segments in an upgraaed 
directory? 2) increasing the pages used by an upgraded 
directory itself? and 3) increasing the pages usee by the 
parent of an upgraded directory due to an increase of the 
upgraded branch. 

The First Method 

Changing the length of segments to reflect the "quota usee" 
up the chain of superior directories is the most flexible 
method of using this information channel. However, this 
facet of the problem can be blocked by reaulring that a 
segment have the same classification as its panent directory 
and that every upgraded directory have a terminal aucta. In 
this way, the pages of a segment are always chargeo to tra 
quota of a superior directory having the same classification 
as the segment. Hence, one cannot pass information down 
merely by changing the size of a segment and causing the 
"quota used" number to change in some superior directory. 
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The Secono Method 

Pages of an upgraded directory itself are charged to a 
superior directory of lower classification. This could 
become a write-aown information channel when a process of 
clearance X adds branches to an upgraded directory with 
classification X, causing the rumber of directory pages to 
grow. The "quota used" number in the superior directory 
would reflect this change and could thus be seen by a 
process whose clearance was lower than X. However, deleting 
branches will not cause the size of a directory to decrease. 
(This is true* due to the current implementation of 
directories.! If this facet of the quota problem was not 
eliminated* its usefulness as a means of compromising 
information for the malicious user is still very limited 
since* 

- It can only be used by a Trojan Horse or cooperating 
processes (See Section 3*5.5). 

- A process can only influence the size of a directory in a 
secondary manner, such as by creating a new branch and 
checking to see if the directory is large enough. 

- A process can write-down only 6 bits (1 BCO character) 
per directory (l to 6** p3ges.) Using two upgraded 
directories in the same parent will not be much help 
since it would provide only 7 bits, due to the additive 
nature of the "quota used". 

- To use this information channel for writing-down N 
characters (6*N bits) in parallel* a malicious user would 
require N directories of the lower classification, each 
with an upgraded directory, and a starting pool of at 
least 66*N unused pages of his quota. 

- A directory cannot be decreased in length by a process. 
This can only be done by a long salvage after a system 
shutdown or by deleting the directory (a process with the 
clearance to add branches to an upgraded directory ooes 
not have the clearance to delete the directory). 

- A process must delete al I branches in the upgraded 
directory and synchronize (using another directory) with 
a process of lower clearance to have the upgraded 
directory deleted and recreated, before another 6 bits of 
information can be passea. Otherwise, a record quota 
overflow will be reached rather quickly. 

This information channel could be eliminated by charging all 
directory pages to its own quota. However, this involves a 
redesign of the entire quota mechanism and would impact the 
activation and deactivation of directories. Therefore, due 
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to the limited effectiveness of the Information channel and 
the high cost of correction* no attempt will be made to 
close this write-down channel. However* for added assurance 
that it is not being used as a means for compromising data* 
the creation of uograoec oirectories and ever, the 
**get_quota** operation can be audited. 



The Third Method 

This problem is a result of the basic design of a 
hierarchical storage system which uses variable lergtn 
branch entries and contains data of more than one 
ci assi f ication. The space used by the branch of an upgraded 
directory is contained in a superior directory of lower 
classification. Hence* by adding ACL entries to an upgraded 
branch* one could affect the current lencth of a I ewer 
classified directory* which is in turn reflecteo in the 
"quota used" in the parent of that directory. This facet of 
the quota problem also requires the use of a Trojan Horse 
and is even more cumbersome than the others. It can only be 
eliminated by restrictirg upgraoed branches to a fixed 
number of ACL entries. The changes described to close the 
second facet of the quota problem would not help this one. 
The solution of restricting ACL entries does not generali?e 
properly for implementation ana presents a very strange user 
interface. Until a correct I cng term solution can tie 
designed* no attempt will be made to eliminate the last two 
facets of the quota problem. 



3.7.3.2 The OTU and OTM Problem 

Every branch contains two items known as the date-time used 
and the date-time modifieo. A process witn clearance X can 
reference a segment with a classification lower than X 
causing its dtu to be updated. This updated ctu can then be 
observed by a process with a clearance loner than X 3nd 
hence* write-down channel exists. In fact* whenever any 
segment is referenced* all of its superior directories must 
first be activated. Since activation is synonymous with use 
in the present system, the dtu's of all suoerior directories 
are updated whenever a segment is referenced. A similar 
problem is Dosed by dtm. The modification of a segirent or 
airectory causes the updating of dtm not only for that 
segment or directory* but for all superior oirectories as 
well. (This is done to aid the backup system in locating 
modified segments and directories without excessive 
searching. ) 

In order to eliminate the write-down channel causeo by the 
upwards propagation of dtu and dtm* new interpretations will 
be given these two attributes with respect to directories. 
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Currently, dtu and cltm refer to the entire subtree of a 

directory. Instead* dtu anc dtm will be made to refer to 

the directory itself* A neH entry item called "date-time 
subtree modified" (dtsm) will be kept to maintain dumping 

efficiency. The dtsm, however, will be available only to 

the dumper process ana not to ordinary users. (See 
Section 3.12) 

In order to prevent writing down via dtu, it will be 
necessary to further alter the interpretation of etc. 




Implementation of this new interpretation of dtu will be 
relatively simple. The global transoarent usage switch 
(gtus) contained in each AST entry will be manipulated ir a 
new fashion so as to properly control the setting of atu. 
Whenever a segment is activatec, the gtus will be turned off 
if the activating process has the same level and catecory 
set as the segment. Otherwise, the gtus will be turned on. 
Thereafter, any process which takes a segment fault on that 
segment will turn off the gtus if it has the same level and 
category set as the segment. The only exceptions to this 
rule will be special transparent system processes (e.c. the 
dumper and reloader) which will never turn off gtus. 
Whenever the branch of an active segment is updatea. the dtu 
for the segment will be reset only if the gtus for the 
segment is off. 
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3.8 ACCESS TO I/O CHANNELS 



3.8.1 Requirements 

No user process shoulc be able tc directly attach any I/O 
device other than a terminal and then only if it has been 
specifically allocated to the process by a system process. 

Each I/O device must be identified with a I eve I /category . 

Any process performing I/O on a device must only be able to 
perform the operations allowed by the fixed level property 
rules (i.e. only read from a lower "level" devicet only 
write to a higher "level" device* and read/write to a device 
of the same "level"> . 

The "level" of a device must be subject to change by the 
system operator. 

The initial "level" of each device must be controlled by the 
System Security Officer. 

Teletype channels must be identified with a maxiirum "level*" 
so that a user can only create a process of a "level" eaual 
to or below the maximum. 



3.8.2 Oesign Considerations 

One approach considered was removing current hcs_ entries 
for device attachment and using a new gate to restrict 
attachment of all devices other than terminals to system 
daemons only. This approach would require either * ring 
four write-around for hcs_ or else the modification of all 
ring four modules that reference hcs_ attachment primitives. 

An additional consideration was to have the system control 
process manage teletype channels entirely. This concept 
went along with the previous approach* so that teririrals 
coula be handled in a slightly different manner ana still be 
attached by user processes. Complete system con+rol process 
management of teletypes was rejected because* with full 
system control process management of teletype channels* 
there are no ring modules involved in the attachment 
decision, only in the actual attachment operation. 
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Another approach to managing I/O devices was to have 
separate device lists, one for system devices and one for 
user devices. The normal user attempting to attach any 
device would check only that list which applleo to him. The 
configuration deck was suggested as a cortrol for the 
memberships of these lists. This Idea was also rejected. 

The most promising suggestion involved adding a new ring 
table, called the Peripheral Assignment Table (PAT), which 
would be referenced on each attachment operation, to provide 
a level/category check of the device that a process is 
attempting to attach. This idea was adopted as cart of the 
Oeslgn Approach. 

3*8.3 Oeslgn Approach 

The Peripheral Assignment Table (PAT) concept will be 
Integrated Into existing ring tables. Each device which 
could be attached to a process will be described In this 
table. The maximum mode, classification level and category 
set will be Included in the entry for each device. If a 
process attempts to attach a device, the clearance of the 
process will be compared to the cl asslf lcatlor of the oevlce 
to ensure that the process will not "write down" or 'read 
up." The "write up" capability will be alloweo only If the 
device Is a "write only" device (e.g., a printer). 

The use of the PAT, as described above, provides assurance 
that normal I/O operations will adhere to the fixed level 
property rules. It does not, however, prevent the possible 
exploitation of flaws in ring I/O procedures. The 
exploitation of "bugs" contained in I/O procecures has been 
a traditional means of breaking the security of many 
computer systems. Therefore, until ring I/O procedures 
can be certified correct, only trusted system processes will 
be permitted to directly attach any I/O devices other than 
terminals. This restriction will be enforced by moving 
attachment entries from hcs_ to a new gate accessible to 
system daemons only. An hcs_ write-around will be provided 
so that existing da«mon software will not require 
modifications. 

Any process requesting a tape drive to be attached must use 
the new ring one tape management software (TMS). The THS 
will maintain a tape descriptor segment for each tape 
registered on the system. At attachment time the segment 
for the particular tape will be checked to fine the 
requestor's "need to know" access and the classification of 
the tape. A message will be sent to the tape allocator 
process to assign the requesting process a drive of the saae 
"level" as the tape. (Notel at trls point, the ring one TMS 
is choosing the "level" of the drive based on the 
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classification of the tape descriptor segment.) When the 
mcunt request is sent to the operator, the drive 
classif Icatlonr wi I 1 be specified (correctly) and the 
operator must verify that the tape requested has the sarre 
"level" as the drive. This can easily be done by color 
ceding and plainly marking the correct classification on 
both reels and drives. The tape mount must be rejected (and 
tte System Security Officer notified) if there is any 
discrepancy. (see^ Section 3.10 for more details or tape 
I/O). It must be noted tftat *t he primary control on tape 
security is the system operator. The TMS can only check the 
operator. If the operator rraWs a mistake or is "spoofed", 
the TMS cannot, in general, detect the error. 

TJ-ere must be a way to , maintain operational procedure 
consistency and yet allow the system control process, 
running at the unclassified level (see Section 3.11), to 
read Top Secret backup tapes during reload. Operational 
consistency requires the Top Secret tapes to be mounted on a 
Top Secret tape drive. Therefore, a means will be provided 
for the system control process to bypass t*~e fixed level 
property restrictions so it will be able to "read up" in a 
carefully controlled wanner. 
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3.9 SYSTEM PROCESSES AND SYSTEM FUNCTIONS 



Many system services such as logging in and logging out a 
user* printing a segment on the printer for a user, saving 
the contents of the disks on tape, restoring the contents of 
the disks from taoe, restoring the contents of the disks 
when they have been damagec, retrieving a segment that has 
been lost, are performed by special processes, kncwn as 
"system processes." Clearly, these processes need unusuel 
power in order to be able to carry out their ]ob, and, by 
their nature, cannot operate at any single clearance level 
without violating the fixed level property restrictions; 
however, they must n&SLSL violate the fundamental security 
rules. 

For example, some of these processes need the "read" and 
"write" capabilities en all segments in the svstem. Sorre 
need the "status" and "modify" capabilities on all 
directories in the system; some need to communicate back 
and forth with all processes in the system? some need to be 
able to attach any I/O channel. It is obvious that there 
exists no clearance which woulc give a system process the 
right to perform its Job, and still adhere to the fixed 
level property requirements. However, for certification 
purposes, there is a very strong desire to assign a level 
and category to all processes in the system without 
exception. It is understood, of course, that system 
processes must not be bocrno by the fixed level property 
restrictions in order to perform certain tasks: therefore, 
the programs in these processes must "interpret ive I y" 
enforce the fundamentel security rules. 

Use of interpretation rather than fixed level property rules 
by a system orocess, as part of normal system operation, 
will be called an "interpretive operation." Any 
interpretive operations should fall into one of the 
f ol lowing classes: 

a. Access to Segments! the retriever process and the 
system control process (when reloading) must be able to 
read and write segments of any classification, but .sclY. 
to copy properly classified information to ano from 
tape. The I/O coordinator and also the system control 
process must be able to share message segments with 
user processes of any clearance. 
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b. Access to Directories! the system control orocess and 
the retriever process must be able to perform specific 
operations in any directory. 

c. IPC* the I/O coordinator as well as the system control 
process . must be able to receive "wakeups" from 
processes of any clearance, using the interprocess 
communication facility. 

d. I/O Channels! the system control process must be sb | e 
to attach an I/O channel of any classification (See 
Section 3«8). 

Since it is desirable to minimize interpretive operations, 

the strategy for assigning a level to a system process is to 

select the one which causes the fewest interpretive 
operat ions. 

An interpretive operation always involves a process, an 
object, and a time interval. For each interpretive 
operation which it performs, a system process must obtain an 
"exception permission." An exception permission can be 
represented by the triple <P,0,T> — a process P is allowed 
to violate the fixed level property with respect to object 
for time interval T. From the viewpoint of a given system 
process, each exception permission is represented by an 
object or set of objects and a time interval. For example, 
if the unclassified I/O coordinator needs to read a Tcp 
Secret message segment, the exception permission represented 
by 



(all segments, lifetime of the orocess) 



is sufficient to allow the interpretive operation to occur. 
A second permission. 



(al 
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I message segments* lifetime of the process) 



is more restrictive but still allows the operat ior. 
Finally, a third permission, 

(all message segments, while the process is in ring i) 

is even more restrictive but still sufficient. Each 
exception permission has a smaller "exception envelope" th3n 
the preceding one. The second permission restricts the 
class of objects, whereas the third permission restricts the 
time interval as well. This example serves to motivate the 
notions of "object granularity" and "time granularity." 
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The second permission has a finer object granularity than 
the first, while the third permission has a finer time 
granularity than either of the first two. Granularity 
should be Interpreted to be the scope or envelope of access 
granted to a system process for an interpretive operation. 

For any interpretive operation* the finest granularity which 
still allows the operation is most desirable from the 
standpoint of the principle of least privilege. For the 
above example* the class of objects (which has only one 
member) represented by 

(the TS message segment for dprint queue 3 to 
the printer in room *»05) 

may well have the finest sufficient object granularity. 

Two general approaches to managing the use of exception 
permissions have been considered during the design analysis* 
These two approaches* called the "privileged function" 
approach and the "privileged process" approach, are 
descnibed below. 

The privileged function approach is one which permits the 
finest possible time and object granularity to be enforced. 
Essentially* this approach provides a special ring o 
primitive to perform each different interpretive operation. 
Access to these privileged functions is restricted to 
specific system processes by use of ring o gates having 
appropriate access control lists. Under this scheme, object 
granularity can be made as subtle as one desires. Also, 
time gnanularlty can be tightly controlled. If an 
Interpretive operation is performed entirely within nlng 0, 
then the call into ring end the corresponding return 
delimit the time interval of the exception permission. It 
is . not only the absolute size of the time interval *hlch is 
significant, but also the fact that contnol neven exits the 
trusted ring domain during the interval. Hopefully, this 
will reduce the effort needed to certify outer ring 
procedures which perform interpretive operations. The 
privileged function approach alsc provides a very natuncl 
and simple means for auditing interpretive operations. 

The privileged function approach is not without its 
disadvantages and limitations from the viewpoint of impact 
on current implementation. The use of restricted gates 
tends to tie procedures to processes. Currently In Multlcs, 
system processes use many of the same library procedures as 
do other processes* If* however, system processes were 
required to employ special gates to perform privileged, but 
otherwise common operations (e.g. deleting a segment), then 
special versions of many library procedures would be neeoed. 
The daemon software itself would require numerous 
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modifications to convert cat Is to standard library 
procedures and standard ring gates to calls to special 
library procedures and special ring gates. And, of 
course, the new ring privileged functions would have to be 
provided. Therefore, from an Impl ementa ion standpoint, the 
privileged function approach Is unattractive. Also, it 
should be recognized that this approach Is not appropriate 
for all types of interpretive operations. For example, 
asynchronous events, such es the receipt of an lpc wakeup, 
cannot be handled in this manner. In many cases, the time 
interval of an exception permission cannot be tightly 
controlled. Consider, for example, the use of privileged 
functions to initiate segments or to attach I/O channels. 
Although the granting of these privileges can be restricted 
to ring 0-. the subsequent use of these privileges cannot be 
so restricted. Hence, while it may not be difficult to 
locate the intervals within a program in which an exception 
permission is in use, it will be necessary to trace all 
possible side-effects. System auditors must ensure that a 
system process is memoryless with respect to each fixed 
level property exception. This will, in general, require 
full examination of every program which performs 
Interpretive operations. Hence, a substantial certification 
effort will still be required for outer ring daemon 
programs. 

The privileged process approach to handling Interpretive 
operations Is one which attempts to minimize implementation 
difficulty. In its simplest form, this approach merely 
requires a per-process switch to indicate whether or not a 
process has "system privileges." This switch (presumably 
stored in the Pds) would be Interpreted by those ring 
modules responsible for access computation. Essentially, 
fixed level property access checking would be effectively 
disabled for all processes having systeir privileges. 
Clearly, this scheme requires comparatively little effort to 
Implement. All that is necessary Is a mechanise to 
initialize the privilege switch and modifications to suspend 
fixed level property access checking for processes tavlng 
the switch turned on. Unfortunately, this approach pays 
little heed to the principle of least privilege. Also, this 
approach has the disadvantage that fixed level property 
exceptions occurring within a program will not be explicit 
In the code, but rather implicit in the fact that the 
executing process has system privileges. Thus, the task of 
certification seems more difficult as compared to the 
privileged function approach. 

The basic privileged process approach could, of course, be 
greatly elaborated. Object granul arlty coul d be enhancec by 
use of multiple switches, each corresponding to a different 
class of objects. Also, time grsnularlty could be enhanced 
by setting and resetting these switches frequently. Taken 
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to the limit, this scheme begins to resemble the privileged 
function approach. A switch, or set of switches, could be 
turned on before each standard ring call, and then reset 
upon return. However, the finer the granularity, the more 
difficult the implementation; hence, the principal advantage 
of the privileged process approach is lost. 

It is expected that some hybrid of the two approaches 
described above will be adopted in order to obtain a 
practical compromise between ease of validation and ease of 
implementation. The specific nature of the hybrid approach 
will depend upon design details to be considered during 
implementation. 
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3.10 I/O DAEMON COMROL IN A SECURE ENVIRONMENT 



3.10.1 Requirements 

The primary requirement of the Air Force Oata Services 
Center is that no user of the Mul tics system be able to 
directly control any external I/O device (other than his own 
terminal). Therefore, each I/O device must be control leo by 
a system process to provide the needed I/O capabilities. 
The devices that will be controlled by system processes will 
be the card reader, the card punch, central site printers, 
remote printers and tape drives. 

For each line printer, an operator (other than the central 
site operator) will always be in attendance. This operator 
will be the primary "controller" of the line printer. The 
detailed requirements for operating local and remote line 
printers are as follows* 

1. During operational hours, if the line printer is 
powered on and the system is running, the line printer 
should be kept busy as much as possible. 

2. If the current queue being processed by a line prirter 
is exhausted, another queue should get serviced 
automatically (within operational constraints). 
Separate queues will be kept for each cevice. For a 
given device, the queue 1 requests for any level should 
be processed before the queue 2 requests, etc. 

3. There must be an accountability fcrm terminal 
associated with each line printer (local or remote). 
Nothing will be printed on the line printer until the 
controlling process has attached the terminal bv 
specific action on the part of the printer operator. 
During printer operations, there nil I be one 
accountability form producec for each copy of each 
segment printed (one per banner). 

<♦. It must be possible for a printer operator to request a 
sample accountability form to be printed on the 
terminal to verify proper alignment of the forms. 
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5. It is required that both the accountability form 
terminal and the line printer be able to oetect an "out 
of paper" condition ana signal this condition to the 
process control I ing the device. 

6. It must be possible for the printer operator to start 
and stop operation of the line printer. 

7. The printer operator must also be able to restart or 
reprint requests that are either in mio-axecut ior or 
that have been processed but have not been processed 
correct I y • 

8. The amount of communication necessary between the 
printer operator and the central site operator must be 
kept to a minimum. 

9. The banner for all printed output must identify the 
classification of the highest level of data that can be 
contained in the printout. 

1C« At the user's request, oage headers ana footers must be 
supplied on each page of printed output which will 
indicate the classification level of the segment from 
which the printec information was obtaineo. The header 
and footer labels will be optional, however the default 
will be to orint labels. If desired, the user can 
replace the segment classification with an arbitrary 
string. 

11. The current "header" and "destination" options will be 
retained for distribution point information only. 

12. The accountability form will be f i < led in with all 
pertinent information relative to the request that It 
describes . 



A new capability must be supplied to allow a system process 
to perform tape I/O based on user requests. The basic 
requirements for handling tape I/O are as follows! 

1. Only system processes will be able to directly attach 
tapes. 

2. Normal users will be able tc place a tape read/write 
request in a queue for a system process to perform the 
actual information transfer. 

3. When the tape data is online, the user will have to 
reference the data as a segment or multi-segment file. 
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k. Commands must be provided to allow users to make tape 
requests. 

5. Tapes must only be mounted on physical drives of the 
same "level" as the tape. 

Modifications must be made to the present card input scheme. 
The basic requirements for card input are as follows* 

1. Only system processes will be able to directly attach 
the card reader. 

2. The operational staff must not be burdened with the 
longterm storage and handling of a large volume of card 
decks. 

3. The owner of a card aeck will be responsible for 
identifying the classification of the deck at the time 
it is submitted to the operations staff for input. 

t*. A card deck submitted for input will be read into an 
online segment having the same classification as the 

deck. 

The standard Multics card punching capabillMes, which 
allows queued punch nequests and user specified punch code, 
must be enhanced to ioentify the classification nf the data 
being punched. The amount of cand punch usage is 
anticipated to be low enough that system produced 
accountability forms ane not nequined. A combination of 
administnative orocedunes and system software should be used 
to pnovide a secune method of cistnibuting classlfiea cand 
decks. 



3.10.2 Oesign Considenat 1 ons 

The message segment management design outlined in Section 
3.5 fonces the design away fnom the current Multics queueing 
strategy. Fon each device type supported we must provide 
sepanate queues fon each classification level supportec by 
the system. However, unclassified only degenerates to the 
current Multics strategy. 

The design alternative of having one device driver for each 
permissible "level" for each device type was rejected due to 
the high overhead required in waintaining several "Idle" 
driver processes and in having the I/O coordinator multiplex 
I/O devices and accountability f crm terminals between driver 
processes. 
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3.10.3 Oesign Approach 

The approach for providing external I/O capabilities is 
essentially that of the Multics standard product, i.e. an 
I/O coordinator process and one driver process per device. 
For each device type supported by the system, there will be 
one message segment queue per "level" or, if desired, 
several queues per "level" having different priority 
ratings. The I/O coordinator must have the ability to 
access these queues at alt "levels" and to communicate via 
IPC with driver processes at all "levels." The driver 
processes will obey the standard fixed level property rules 
concerning attachment of I/O devices and segment references. 



I/O Cooroirator 



There is no "level" at which the I/O coordinator can operate 
strictly within the fixed level property rules. Therefore, 
it will operate at the lowest possible "level" with the 
special privileges needed. This choice offers the advantage 
of not requiring special IPC privileges for the driver 
processes with which the I/O Coordinator communicates. The 
I/O coordinator will have the following characteristics in 
the two-level security environment: 

1. There will be multiple queues, specifically one per 
level per device class per priority. 

2. The I/O coordinator will allocate tasks to various 
driver processes where esch task is defined as a 
request of a single user. 

3. The I/O coordinator will be responsible fcr making the 
decision of where to send an individual task* (i.e. to 
the appropriate device driver process at the correct 
"level"). The decision will be based in part on the 
minimum expected device level for a given class of 
device. This will, for example, allow the I/O 
coordinator to allocate all tasks for a remote line 
printer to a driver process at "level" n.» If the remote 
printer is never to be classified below "level" n. At 
the AFDSC central site, where printers will be operated 
at both Secret and Top Secret, the minimum expected 
"level" decision criterion will prevent requests from 
Secret users and below beirg sent to a Top Secret 
device, so that there will be a minimum of 
over — classification at distribution time* The operator 
will be able to reconfigure the queues by changing the 
minimum expected "level" for a device class. 
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<t. The I/O coordinator will not make decisions as to which 
device drivers to create. This Hill be done routinely 
by the system operator manually logging in the connect 
dniven at the connect "level." The openston will also 
be nesponsible ton necl assif y ing devices when 
necessany. 

5. The I/O coondinaton will have to penfonit intenpnetive 
secunity operations to be able to nead and delete 
nequests fnom each message segment queue at each 
"level" in the system. Also, the I/O coondinator irust 
penfonm intenpnocess coirmunicat ion with dniven 
pnocesses at vanious levels. 

6. A temponany histony file will be necondec on a pen 
dniven basis ton nestanting nequests* which have 
abnonmally tenminated on which wene sent to a pninten 
that had no papen. 




8. Pant of the optional data supplied by a usen will be an 
event channel and pnocess ID which can be usea fon usen 
notification at the completion of his request, assuiring 
that the process is still active at the tine the 
nequest is pnocessed. 

9. The devices that wilf.be contnolled thnough the I/O 
coondinaton and dniven pnocesses will be the cand 
reader, the card punch* centnal printers, nemote 
pnintens* and tape dnives. Thene will be one dniven 
pnocess fon each incividual device. 



Line Pnintens 



Both local and nemote line pnintens will be handled by 

pninten dniven pnocesses. Pninten dniven pnocesses will be 
operated with the following constnaintsi 

1. The level of the dniven will be equal to the level of 

the device. The level of the device will be used in 
detenmining the banner classification name fon the 
pninted output. 
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This process will not be able to access data in 
segments of a higher level* 

2« The driver process hIII be passed requests generated 
from various "level" user processes as decided by the 
I/O coordinator. 

3. The driver will add optional header and footer 
labels on each page of output indicating the level of 
the segment being printed. This will be explained in 
more detail later. 

*♦• The printer driver process Hill be responsible for 
interpreting the "need to know" access of the requestor 
from the access control list of the segment that is 
being printed (The I/O coordinator will interpret the 
user's access for deleting* when requesteo.) 

5. The driver process will require an accountability form 
terminal to be attached. At no time will the driver 
process attach its printer before the attachment of the 
terminal. If the terminal is inoperativet the printer 
is also assumed to be inoperative. 

6. The driver process will be modified to prepare 
accountability forms. 

7. There will be a sequence number associated with each 
banner sheet to help operations burst the printer 
output. Since this number will be generated by a 
driver process at request processing time* it will be 
unknown to the user. Therefore, it cannot be useo ss a 
claim checK to pick up printed output. 

8. Driver processes will accept commands from the 
accountability form terminal. These commands will bet 

start start printing requests 

stop stop at next request 

abort stop immediately 

sample print sample fcrm 

When the printer operator types "sample" on the 
terminal, the driver process will produce one sairple 
accountability form to verify alignment of the paper. 
However, it will not start producing outout until the 
operator enters the start command. 

9. The driver process will prepare an accounting file to 
charge eacn user for the use of the printer. 
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Printer output will have a banner* optional page labels* and 
an accountability form to help identify the classification 
of the printed information. The banner will have an added 
field of large block lettering to indicate that the printed 
output "may contain <level>" where <level> is the 
classification level (without the category set) of the 
device on which the information was printed. The mnemonic 
used in the banner must be no longer than thirteen 
characters. (The same mnemonics will be used throughout the 
system.) The classification on the banner cannot be 
controlled by the user and will be the same as that 
indicated on the accountability form. In adaition to 
printing the classification level in large block letters* 
the full classification, including categories, will be 
printed In stan Jard-slze letters. 

The header and destination options to the dprint command 
will still operate as In the standard Multlcs system. 
However, the information supplied in this manner must not be 
used to determine classification of output. Rather, the 
information should be considered as user delegated "need to 
know" authorization to be used to help in the distribution 
of output. 

Header and footer page labels may be placed on each page of 
printed output by use of a new dprint ootlon. (The default 
will be no page labels.) The optional label will contain 
the classification of the segment from which the information 
was obtained. Alternatively, a user may request that an 
arbitrary string (less than 132 characters) be used In place 
of the segment classification by using another new option to 
the dprint command. Header and footer page labels will be 
centered across the page. It srould be recognized that the 
use of page labels will recuce the number of text lines per 
page, and hence, may upset the page alignment of formatted 
output. 



Tapes 



Tapes will be handled as part of the general I/O scheme 
mentioned above. The "level" of a tape driver process will 
always equal the "level" of the requests which it handles. 
A tape driver process will be permitted read/write access to 
tapes having the same "level" and read-only access to tapes 
of a lower "level." Write-only access to higher level tapes 
will not be permitted since there Is no apparent V3lue in 
such a capability. 

The user Interface to the tape I/O mechanism will permit the 
user to request that a tape be read Into a segment or that a 
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segment. 

1. The "level" of the tape driver process will be the same 
as the "level" of the requestor. However, only Secret 
and Top Secret processes wl If be used at AFDSC. 

2. The "level" of the tape drive that will be chosen to 
satisfy a given tape request will be the same as the 
"level" of the tape as indicated by the tape Descriptor 
segment. (The operator* however* is the orlirary 
control that the "level" of the drive matches the 
"level" of the reel .) 

3. If the level of the driver process is greater than the 
"level" of the tape drive, the attachment will be read 
only. 

*♦. Tape driver processes will operate within the fixed 
level property restrictions. Therefore* any segments 
created while reading tapes will have the same "level" 
as the driver process. 

5. The access mode given to the requestor for a read 
request will be the mini sum of the requested mode of 
access and the effective moce of access for that user 
to the tape descriptor segment. 

6. On a read tape request, the Information will be stored 
in a multi-segment file in a tape pool directory of the 
correct level using the taoe number as the segment rame 
(unless another pathname has specified by the user). 

7. Storage management of the tape pool directories will be 
a problem. A taoe Image segment or multi-segment file 
(which can occupy thousands of pages of online storage) 
must remain in Its tape pool directory long enough to 
be processed by the user. The required retention time 
will, of course* vary from one tape segment to the 
next. In order to al low the user to aid in storage 
management, a "delete" option will be provided for the 
tape write request. If specified, this option will 
inform the tape driver process to delete a segment 
after writing it to tape. As a further aid in storage 
management, it may also be desirable to give users 
modify oermlssion In an inner ring to the tape pool 
directories. A command could then be provided which 
deleted a tape segment at the user's request while 
operating in an inner ring. This would ensure that a 
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user could only delete his cwn tape segments* and could 
properly handle the case of shared tape segirents. 
Periodically* It will be necessary to delete from the 
tape pool directories these segments which have 
exceeded a specified age limit. 

8. The "Multlcs standard tape" information stored In the 
tape descriptor segment will be used to identify which 
device interface module the driver process will use to 
read/write the tape. This provides a means of 
automatically handling both Multlcs standard format 
tapes and non-standard format tapes through the same 
user interface. 

9. A tape write request will write whole tapes only. A 
tape read request may. read a whole tape or else msy 
specify a portion of a tape by supplying two 
end-of-file marks at which to start and stop reading. 
Individual records will net be read or replaced on a 
tape. 

10. The user will be able to specify the pathname to be 
used for the read/write operation if he wants to use a 
different segment than would be provided in the tape 
pool directory. 

Notet The user must h£ve enough quota to hold an entire 
tape if he wants to read a tape using a SDecified 
pathname. 



Card Input 

Card input wl I I be handled much the same as in the present 
system. A user will submit his card deck to the operations 
staff along with a special contrcl card specifying a useric. 
The deck will then be read Into a segment created in a card 
pool directory, and the specified userld will be acaeo to 
the access control list of the segment. There will actually 
be one card pool directory per "level." The omner of a oeck 
will be responsible for identifying the classification of 
his deck and thus the appropriate card pool directory. 
Unlike the present scheme* no link to the card image segment 
will be created for the user. This eliminates a 
vulnerability of the present card input mechanism whereby a 
user could cause a link to be placed anywhere In the 
hierarchy. Instead* the user will be given a seauence 
number by which to identify the card image segment created 
for his deck. When logged in* the user will employ a new 
command which takes the sequence number as an argument, 
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locates the associated card lirage segment, copies It Into a 
new segment named by the user, and then deletes the card 
Image segment. This new command will operate In an lrner 
ring. Users will have no access to card image segments or 
card pool directories in ring *♦. Periodically, it will be 
necessary to delete from the card pool directories trose 
segments which have not been copied and deleted within a 
reasonable period of time. 



Card Output 



Card output presents a new problem In identifying the 
classification of the Information punchea on the deck. 
Printed output is initially in one piece and each page can 
be labeled. Card decks, however, are not connected and 
cannot be labeled by the system except for deck header and 
trailer cards. Therefore, it is easy for caro decks to get 
mixed with other cards of olfferent classifications unless a 
new procedure is adopted. 

The obvious solution is to use cards of different colors for 
the different deck classifications. This solution carries 
with it some operational problems which must be mentionec. 

First, for this system to be effective, a giver card color 
must always be used to identify the same classification. 
This is needed to ensure correct handling of the decks by 
the distribution staff and operations personnel. Therefore, 
if the supply of cards for a given color is exhausted, all 
card output for that classification must be suspended. 

Second, a card deck of a given color is difficult to 
declassify since the meaning of the color must be preserved. 
Therefore, the downgrading of a card deck irust be done by 
repunching the entire deck on cards of a different color and 
destroying the original. This operation must be 
administratively forbidden except under carefully controlled 
conditions and only when approved by the System Security 
Officer. 

Third, to avoid the problems of over-classification, the 
punch must be handling requests of only one classification 
during any period of time. This means that operator 
intervention is necessary every time a request queue of a 
different "level" 1 is to be serviced. 

The Multlcs punch driver process will be modified to support 
this mode of operation by the following software 
capabilities and administrative procedures! 
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1. The punch driver process will operate within the fixed 
level property restrictions for access to segments and 
I/O channels. 

2. To prevent over-classification of punched output, the 
driver process should operate at the " level ^ of the 
requesting process rather than at a higher "level." 
Also the "level" 1 of the card punch should be the saute 
as the "level" of the driver process. This will ensure 
that the color of the card deck will indicate the 
classification which corresponds to the clearance of 
the requestor. The I/O coordinator will help to 
separate the data of different request "levels" through 
the "minimum expected level" decision mechanism 
described above. Only if the operational buraen of 
downgrading a portion of the decks punched is 
acceptable, should the "minimum level" of the punch be 
set higher than unclassified. 

3. The I/O coordinator will inform the operator when the 
queue of requests for t re current device driver is 
empty, to allow him to reclassify the device for 
operation at a new "level." 

<♦. An operator will change the operating "level" of a 
punch driver byJ 

logging out the driver process. 

reclassifying the punch to the new "level"; 

changing the color of the card supply? 

logging in a punch driver of the correct "level." 

The driver process will inform the I/O coordinator of 
its clearance which will be used in routing user 
requests. However, the security of the punched output 
is totally dependent upon the correct caro color being 
loaded by the operator. 

5. Accountability forms for the card decks will have to be 
prepared manually. The normal terminal output of the 
driver can be used to separate the decks to ensure a 
one to one correspondence between accountability fcrirs 
and card decks. 

6. Users should be discouraged, administratively, from 
requesting a dpunch of a segment which has 



requesting a dpunch of a segment which has 
classification which is lower than the clearance of hi 
process. This would result in implicitly upgrading th 
information, resulting In overcl ass if icat ion. 
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7. The information provided by the terminal output of the 
driver process nil I be stored in a segment to provide 
an online audit of completed punch requests. 
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3.11 SYSTEK CONTROL PROCESS 



3.11.1 Description 

The system control orocess performs the tasks of system 
initialization, answering service and system control. 

In its function as the systeir initialization process, it 
reads a system bootstrap tape and creates the Multics 
environment. If necessary, the system control process is 
used to reload the file hierarchy from backup taoes. 

In its function as the answering service Drocess, it 
"listens" to all teletype channels. When a terminal 
powers-on, it sends an interrupt to the system control 
process. The answering service then prints a greeting, and 
validates the login or dial command. In the case of a valid 
login command, the answering service creates a process in 
the name of the user, allocates the console I/O channel to 
the process, and sends the process a wakeup. The answering 
service also handles recuests from the user's process for 
new_proc and logout, and coordinates requests for table 
updates from the System Administrator and Project 
Administrators . 

In its function as the system control process, It records 
accounting Information, validates requests for I/O devices 
(tapes, etc.), controls the consoleless daemons, and 
provides an operator command interface. 

3.11.2 Requirements 

It is a requirement that these functions continue to work, 
without substantial implementation modi f icat iors. 

It Is a requirement that the system control process violate 
the fixed level property as little as possible. 
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3.11.3 Chosen Approach 

To minimize the need for special access and the necessity to 
rewrite code. the system control process will run at the 
unclassified level. In this way. all System Administration 
segments (e.g. user registration and accounting) will be 
unclassified. Thus. System Administration and Project 
Administration will Pe unclassified for nearly all functions 
and will require no violations of the fixed level property. 

IPC (interprocess communication) will be modified to provide 
the necessary communication paths between the system control 
process and user processes. IPC Mill have a privileged 
entry to set a flag which will allow the system control 
process to receive messages from any "level" process, 
despite the fact that it Is unclassified. By normal 3ccess 
rules it will always be able to send IPC messages to any 
process*, (see Section 3»5) 

In communicating with other processes, the system control 
process will be able to use specified message segments of 
any "level." (see Section 3.9) 

The system control process, in its function as the system 
initializer, will initialize the ring tables used to 
validate all attachments of I/O channels. (See Section 
3.8. ) 

As part of, its function as the system control orocess, it 
will execute operator commands for reclassifying I/O 
channels, handling tapes, etc. 

See Section 3.3 for an explanation of absentee and login 
validation procedures. 

See Section 3.13 for an explanation of the role of the 
System Control Process in reloading. 
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3.12 OTHER SYSTEM PROCESSES 



3.12.1 The Backup and Dumper Daemons 

Two system daemons, namely "Backup" and "Dumper." are 
employed to perform file system backup. These two daemons 
scan the hierarchy and copy to tape "eligible" tiles and 
directories. The eligibility of a file or directory for 
backup dumping depends upon the dumping mode. Incremental 
dumps* performed by the backup daemon* dump files and 
directories which have been modified since they were last 
incrementally dumped. Complete dumps* performed (less 
frequently) by the dumper daemon, dump all files and 
directories. 

In the past* two separate daemons were needed in order to 
run Incremental and complete du'mes concurrently. However, a 
multiple login feature is now available which permits a user 
(or daemon) to be logged in several times concurrently with 
the same principal identifier. Hence, it is feasible to 
have only a single daemon for backup purposes. Therefore, 
Dumper. SysOaemon will be discarded In order to minimize the 
number of system daemons ard to simplify the access 
requirements for file backup. 

The backup daemon will run with the highest clearance level 
so that It may read all files and directories. This 
implies, of course, that backup tapes and dump maps will, as 
desired, have the highest classification. The backup 
daemon, being a trusted process, will be permitted to 
directly attach tapes. 

The backup daemon must set the date-time dumped (dtd) for 
all segments and directories. Currently, modify permission 
on a directory Is needed to set dtd for branches contained 
within the directory. This Implies that the backup daemon 
would need the ability to modify directories at all levels. 
This problem Is really a manifestation of a more basic 
problem. Intuitively, It makes little sense that a user is 
forced to give the backup caemon modify permission to 
directories. The function of backuD is essentially "read 
only" in nature. Therefore, read access to a segment will 
be sufficient to set dtd for that segment. 
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The date-time dumped (dtd), date-time modified (dtm), 
date-time used (dtu), and date-time entry modified (dtem) 
segment attributes Hill no longer be subject to explicit 
modification by users. Currently, these date-times are 
writeable via hcs_ and hence are not trustworthy. 
Therefore, hcs_ entries which set these date-times will be 
removed. 

Certain changes to the oumper program (used by the backcp 
daemon) will be required. First, the new I evel /category 
information must be backed up and hence must be added to the 
dump record format. Second, a new hphcs_ call must be 
provided to permit the backup daemon to set dta. And third, 
a new branch attribute called the date-time scbtree modified 
(see Section 3.7.51 must be Introduced to guide incremental 
dumping. 

The backup daemon will not violate the fixed level property 
rules in any manner. 



3.12.2 The Retriever Daemon 

The retriever daemon is used to recover selected files and 

directories from backup tapes at the user's request. In 

order to read backup tapes, the retriever must run with the 
highest clearance. 

The retriever will require certain special privileges. In 
order to restore files and directories to the hierarchy, the 
retriever must be able to create branches of all 
classifications and to modify segments and oirectories of 
all classifications. 

Certain modifications to the retriever program will be 
required. New ring calls must be inserted to properly 
restore the classifications of segments and directories. 
Also, a new hohcs_ primitive -hII I be provldeo to allow the 
retriever to restore the various date-times (since these 
will no longer be writeable via hcs__ as described above). 




attempt to retrieve 

c 

I eve I 



lasslficatlon wi I I impl iclt ly reclassify the branch at the 
evel of the directory. If a user wishes to avoid such 
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reclassification, he can rename or delete the existing 
directory, or else can retrieve the branch into a different 
directory (as described below). 

It is also possible* but unlikely* that an attempt could be 
made to retrieve a segment into a directory of lower 
classification. This could only occur if a directory were 
created, deleted, and then recreated 3t a lower 
classification. Oue to the quota problem (see Section 
3.7.*f), segments are required to have the sa&e 
classification as their containing directory. Therefore, 
ring will refuse to set the classification of a segment 
branch higher than that of Its containing directory. Since 
the retriever cannot be permitted to declassify a segment* a 
request to retrieve a segment into a directory of lower 
classification must be rejected* A user can avoid this 
problem by renaming or deleting the existing directory or by 
retrieving Into a different directory. 




i. A user can retrieve anything under his hotre directory. 
A Project Administrator can retrieve anything under his 
project directory. A Systett Administrator can retrieve 
anything. 

2. A user must have write access to the segment if it 
exists online. Otherwise, he must have mooify 
permission for the nearest superior directory which 
exists online. These checks can be made by the SSC or 
his assistant. (Note that ender this scheme, granting 
access to a segment implies granting access to tre 
entire backup history of the segment. This should not 
be much of a problem, however, since segments are 
rarely "reused" for different purposes.) 

Once a user's right to retrieve a segment or directory has 
been established, he can then retrieve trat segment or 
directory into any existing directory in the hierarchy for 
which he has append permission. In most cases, a segment or 
directory will be restored to Its original position within 
the hierarchy. In some cases, however, a user may request 
that a segment or directory be placed in a new position 
within the hierarchy. This is known as a "cross-directory" 
retr leva! . 
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It may also be desirable to accept retrieval requests from 
remote locations. No formal mecranism currently exists for 
this purpose. In current practice, retrieval requests are 
sometimes accepted over the telephone. It should be noted 
that retrievals cannot be used in any manner whatsoever to 
declassify information. Hence, tel eprone-requested 
retrievals can be performed without fear of such a security 
breach. However, sabotage is possible by simply overwriting 
online segments with backup copies. Also, need to knew 
access can be compromised by a cross-directory retrieval. 
Therefore, positive user identification should at least be 
required for all cross-director v retrievals, as well as for 
all retrievals outside of >udd. 

3.12.3 The Repair and Ring_i_Repair Daemons 

Two daemons, nauely "Repair" and "Ring_l_Repair," are used 
to perform emergency fixes to the system. The Ring_i_Reoair 
daemon runs in ring one in order to handle special rirg one 
problems, e.g. the installation of a ring one gate. 8otn 
daemons require essentially unlimited access to the system 
via ohcs_ and hohcs_. The repair daemons shoul a run at 
system high, since they have access to all information in 
the system. They may have to "write down" information on 
occasion. 

The passwords for these daemons should be Known only to the 
SSO and should be changed after each logout. At his 
discretion, the SSO will make the passwords available to 
system programmers ana other persons needing to use the 
repair daemons. It may be desirable for the system to 
actually require a password change for these daemons 
(performed by the SSO) between each lagout ard next login. 



3.12.** The Metering Daemon 

The Metering daemon is used to generate system performance 
graphs and other system meters. For this purpose, phcs_ 
access is required. The daemon probably shoulc run system 
high, because the metering inforiration may be en Information 
channe I • 



3«12«5 The Print_Oump Daemon 

The Print_Oump daemon is sometimes employea to orint 60S 
dumps (see Section 3.13*1> during normal Multics operatior. 
A BOS dump may reside either on tape or in a special area of 
online storage known as the OUMP partition. At system 
initialization time, the initializer copies dumps from the 
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OUMP partition into the Multics hierarchy. These EOS dump 
segments* as well as BOS dump tapes* will be classified 
system high and hence* the Print_Oump daemon must run with 
system high clearance. This daemon* being a trusted system 
process* will be permitted to directly attach tapes. In 
current practice* the Print_Oump daemon may also directly 
attach a printer. In the sectrlty system* rowever* it is 
desired that all printed output be identified by a security 
banner. Therefore* direct printer attachment will rot be 
permitted. Instead* formatted dump segments will be 
dprlnted. 
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3.13 CRASH RECOVERY 



3.13.1 BOS 

80S (Bootload Operating System) Is a collection of urograms 
used to perform a number of basic functions such as loadirq 
a Multics system tape, assisting in Multics shutdown, and 
dumping the Multics machine i itage (usually following a 
system crash). BOS also plays a significant role in file 
system backup and recovery operations. PeriocicaHy, 
Multics is shut down so that BOS may perform a "SAVE." A 
SAVE essentially copies all of online storage onto tape, 
thus establishing a checkpoint for use in file system 
recovery. In the event of online storage loss, 80S is 
called upon to perform a "RESTOR," i.e. the loading of 
online storage from SAVE tapes. 

BOS will have no knowledge of Multics security controls. 
Operational control of BOS is sufficient to ensure security. 

BOS dumps of the Multics irachine image may contain 
information of all classifications and hence will be treated 
as Top Secret. BOS itself will provide neither security 
banners nor page labels for printed output. To do so would 
add unwanted complexity to BOS, and would require that 
specific classification names, e.g. "Top Secret," be 
included directly in BOS programs. Since such names are 
intended to be installation parameters, a different version 
of BOS would be required for every installation. 

BOS dumps may be immediately directed to a printer, or else 
may be saved on tape or disk for later printing. In the 
former case, it is recommended that special paper be used to 
indicate the classification of the printed outDut, e.c. 
paper having a "Top Secret" water mark. If BOS dumps are 
printed during normal Multics operation, banners and page 
labels can be added at that time. 

3.13.2 The Salvager 



The salvager is a group of programs designed to detect, 
report, and correct wherever possible any inconsistencies in 
the Multics directory hierarchy. The salvager runs within a 
special version of the Multics operating system and utilizes 
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a separate partition of online storage. The salvager is 
employed following either a normal Multics shutdown or an 
emergency shutdown Instigated by a system crash. 

The salvager will be knowledgeable of security controls as 
they apply to the file system. The only kinds of 
security-related Inconsistencies which can be detected by 
the salvager are violations of the non-decreasing 
classification rule of the hierarchy. Unfortunately, 
however t such inconsistencies cannot be automatically 
corrected. If an unclassified directory Is discovered below 
a Secret directory* it does not seem warranted to delete the 
unclassified directory. It seems more reasonable perhaps to 
upgrade the directory and its inferiors where necessary 
since this cannot compromise security. However, this 
strategy may produce absurd results If, for example* >uad 
became erroneously classified Secret due to a system crash. 
Therefore* the salvager will mark a branch "out of service" 
whenever It falls to comply with security regulations. The 
pathnames of such branches will be reported to the operator. 
Explicit action by the SSO will be required after the system 
has been restarted to place these branches back in service. 

The running of the salvager will be enforced by the system. 
Currently, when Multics Is bootloaded without prior 
salvaging, a warning message Is printed for the operator. 
Instead of Just a warning, system initialization will 
actually be aborted. 

There exist four different salvaging modes known as fast, 
active, regular, and long. A fast salvage merely flushes 
the paging device. In current practice, a fast salvage is 
usually performed after a successful emergency shutdown. 
When shutdown succeeds in recovering the file system device 
configuration table (FSDCT) from core, but fails to 
deactivate alt active segments, an active salvage Is 
sometimes performed. An active salvage examines all 
directories which could not be deactivated. If a shutoown 
attempt falls to recover the FSDCT from core, then a regular 
salvage is performed. Only a regular salvage will examine 
all directories and completely rebuild the FSOCT. Hence, 
only a regular salvage is guaranteed to detect all possible 
reused addresses* i.e. pages claimed by more than one 
segment. To avoid possible security violations, such pages 
are zeroed by the salvager. A long salvage is basically the 
same as a regular salvage except that it rebuilds all 
directories (not Just Inconsistent directories) for the 
purpose of directory compaction. It is recommended that 
regular or long salvaging always be performed so as to 
ensure file system consistency. (For the present MIT 
hierarchy, a regular salvage requires about ten minutes to 
run. Therefore, the time saved by use of the fast or active 
salvage modes Is negligible. However, It is expected that 
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the time to perform a regular salvage will Increase 
approximately linearly with the number of branches in the 
hierarchy. > 

As with 80S, the salvager will provide neither security 
banners nor page labels for printed output. Special Top 
Secret paper can be used as suggested for 90S output. 



3. 13«3 Reloading 

Following a system failure which causes extensive file 
system damage, it is necessary to recover the former 
contents of online storage from SAVE tapes and backup tapes. 
This recovery operation is known as a RESTOR/rel oad. The 
first step in the recovery procedure is to use BOS to 
perform a RESTOR of the latest SAVE. Next, Mul tics is 
bootloaded and backup tapes produced subsequent to the 
latest SAVE are reloaded in chronological order. Thus, the 
hierarchy is restored to its state at the time of the latest 
incremental dumo. 

The reloading of the file system from backup tapes Is 
presently performed by the initializer. The reason for 
choosing the initializer is because other daetrons carnot be 
logged in until the answering service begins operation. The 
answering service, in turn, cannot be started until all cf 
its data bases have been reloaaed. 

When performing reloading, the initializer will require 
certain special privileges. First, as an unclassified 
process, it must be permitted to read Top Secret backup 
tapes. Second, it must be capable of creating branches at 
all levels and writing at all levels. But as with the 
retriever, the initializer is forbidden to violate the 
increasing classification rule of the hierarchy. 




There exists another type of reload known as a "cold reloac" 
which is not generally used as a method of crash recovery, 
but is sometimes used for special purposes such as directory 
reformatting. To facilitate major operations of this type, 
a complete dump is usually performed immediately before a 
cold reload. A complete dump is usually divided into 
sections, one of which contains all system files. These 
system files are reloaded first by the initializer. Next, 
the answering service Is started so that other system 
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daemons can be logged in to perform the remainder of 
reloading. The retriever daemon can be used for this 
purpose since it will have the necessary privileges* 
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3.11* OPERATOR INTERFACE 



3.1<*.l New Procedures and Responsibilities 

Relatively few changes to the Muitics operator interface are 
anticipated. The operators will be given the new 
responsibility of reassigning cevice classifications. Also, 
tape handling will be somewhat different. Tape drives and 
tape reels will be identified by color-coded classification 
labels. Each registered tape reel will have an associated 
three-letter authentication code to be typed by the operator 
at tape mount time for verification purposes. 

3«l*f.2 Security-Related Messages 

Security-related messages directed to the operator will 
explicitly specify violations* warnings* etc. so that 
appropriate operator action can be taken. Such messages 
will be distinguished by some convention, e.g. preceding 
asterisks. Also, the audible alarm on the operator's 
console will be used to alert the operator whenever his 
attention is required. 
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3.15 ADMINISTRATIVE CONTROL 



3.15.1 Requirements 

The functions of the System Administrator (SA) and System 
Security Officer (SSO) must be as distinct as possible. The 
SA must not be able to downgrade segments* nor assign 
classifications to new users* nor change the classification 
of existing users. The SSO must not be required to register 
new users nor perform accounting. 



3.15.2 Design Considerations 

The primary consideration is that the authority of the SA 
and SSO be clearly delineated. In this way* the SA will not 
be able to perform functions which are the responsibility of 
the SSO* and the SSO will rot be burdened by the routine 
tasKs of the SA. A seconoary consideration is that the 
tools for use by the SSO shoul c be simple and easy to use, 
and should follow normal Multics command conventions. 



3« 15. 3 Chosen Approach 
The SA wl II I 

1. register all users? 

2. perform system accounting functions? 

3. perform default project administration. 

In general* the tasks of the SA will remain unchanged in the 
new system. 

The SSO wills 

1. assign clearances to persons and projects* 3nd assign 
classifications to terminals and I/O devices* 

2. assign the mnemonics for levels and categories? 

3. perform the downgrade functions on segments and 
directories? 
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<t. be responsible for the physical security of all on-site 
and remote equipment, including the integrity of 
interconnecting cables* 

5. be able to force a given user (or all users) to change 
his password? 

6. receive and review all security audit data* 

7. approve retrieval requests (see Section 3*12) » 

8. fix security-rel ated inconsistencies detected by the 
salvager (see Section 3.13> * 

9. set the security audit flags for various personid's and 
pro]ectid*s (See Section 3«16.<»). 

The special commands (e.g. downgrade) used by the SSO will 
contain calls to auditing procedures to record their usage. 
It is also suggested that the console script of the SSC be 
retained as further auditing information. 

Those privileged functions which must be restricted to the 
SSO alone will be implemented via a separate gate segment. 
In this way, the ACL on the qate segment can effectively be 
used to give access to the SSO while denying it to other 
users. The user ring functions (commands for inspecting the 
audit data, and setting the clearances of oersons and 
projects) which are restricted to the SSO will similarly be 
protected by their ACL. 

The tables which are shareo between the SSO and SA are 
updated only by the system control process, and the updating 
tools will be modified to permit only the SSO to set the 
per-person clearances and audit flags in the PNT and the 
pei — project clearances and auoit flags in the SAT. In this 
way, the existing functions of the SA will not be affected, 
and the SSO will assume control of all security-related 
functions. 

Several new tables will be the exclusive responsibility of 
the SSO, including the Peripheral Control Table specifying 
the I/O channel classifications and the terminal answerback 
codes. 



79 



3.16 SYSTEM AUDIT 



3.16.1 Requirements 

The system audit functions should provide a history of 
normal and abnormal system use* or operation, to permit 
regular security review of system activity (per DoO 
5200. 28-M). System events to be included in the audit aata 
aret 

1. each access to a classified file and the nature of the 
access (per OoO 5200. 28-M); 

2. each login and logout* 

3. each unsuccessful login attempt and reason for 
rejection? 

<♦• each rejected access to information due to security 
restrictions and each illegal attempted use (fault) of 
access permission; 

5. all system faults which could indicate attempts to 
subvert the system or to exploit hardware failures? 

6. all security related actions of the System Security 
Officer or the System Administrator; 

7. each time a process awards itself extra privileges* 

8. all completed requests for printed or punched output 
(not terminal output); 

9. all tape mount requests for user tapes. 

Where possible, the recording of audit data must have the 
capability of being turned off on a per user or oer system 
basis. The subverter process, for example, must be known, to 
the audit programs so that its known violations can, if 
desired* be omitted from the audit data. Data reduction 
programs must be provided to prepare summaries of audit data 
for inspection. 
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3.16.2 Design Considerations 

Audit data segments must be writeable by many processes, 
hence, there must be a locking strategy provided with 
assurance that the process locking the data will unlock it 
before it loses eligiblity. These segments must either fall 
outside the security rules, or there must be a data 
segment(s) for each level/category combination used on the 
system. 

Ring zero auditing must be done only when there is no 
directory locked by the subject process to avoid deadlocking 
prob I ems. 

The feasibility of storing exponentially smoothed data on 
the interval between certain events will be examined (e.g. 
average period of illegal opcode faults, average perioc of 
initiate rejection due to security) after more design 
details are known and an assessment of performance impact 
can be made. 

3.16.3 Design Approach 

Each successful login is recorded on the system control 
console output, as well as i r the online log kept by the 
answering service. This log also records each unsuccessful 
login attempt and the reason for rejection. The mechanism 
which records information in this I og wi I I be modified to 
ensure that the following data will be recordec for each 
unsuccessful login! 

login line as entered by user 
hardware channel of the terminal 
answerback code of the terminal 
maximum level of the terminal 
the reason why the user was rejected 
date and time 

In addition, if the person's clearance is less than the 
maximum "level" of the terminal, a "breach of physical 
security" message will be sent to the operator. Also, if 
the number of bad passworos for a given personid is greater 
than the system maximum, an "attempted breach of security" 
message will be sent to the operator and recoroed In the 
log. This count will be reset on the next successful login 
of that person. 
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would log into. Otherwise* a person logging in as the 
System Security Officer could write a program which would 
perform the same security related functions without using 
the the audit interface. The details of which security 
functions must be performed entirely within the user rirg 
will be described when the implementation details are better 
understood. 

The granting of special access privileges to any process 
will be audited by ring 0. 

Any rejected attempt to add a segment to a user's aodress 
space* due to security rules* will be audited by ring 0. 
(Shared data and locking problems will occur here). 

All access violation and illegal opcode faults will be 
audited by ring q. The data recorded for each fault audited 
will include* 

pathname and offset of object denied access 

type of violation (fault) 

••level** of object 

user's effective access mod€ to the object 

•"level" of process ano current ring 

pathname of executing procedure 

user ID of process 

date and time 

(Shared data and locking problems will occur here). 



The classified segment audit data will include* 

user 10 of process 

pathname of the segment 

"level** of the segment 

user's effective access mode to the segment 

date and time 

This capability may introduce significant performance 
degradation in the system ano will generate a large amount 
of audit data (shared data and locking problems occur here). 



The problems of shared data and locking are primarily a 
problem associated with rings other than ring 0. The audit 
data areas must be writable by all processes if the 
information is to be complete. This cannot be done in the 
outer rings without allowing a user process to violate the 
fixed level property. Even if this was alloned* a process 
can lose its eligibility to use a processor while executing 
in an outer ring with a lock set which could cause other 
processes to wait for the locking process to be rescheduled. 
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The mechanism to be used for the ring auditing will be an 
enhanced version of the system error auditing procedure. 
This has the advantage of providing a common interface for 
all system auditing functions. The audit data will be 
stored in a special disk partition and periodically copied 
into segments in the the Multics storage system by the 
system control process. The error type labels on each audit 
entry will be used to separate the security relstec entries 
from other system errors. 

A ring entry Mill be provided to allow administrative and 
security related procedures to record their actiors as 
needed. Access to this gate should be provided for all 
users, but limited to rings of higher privilege than the 
normal user ring tc avoid a potential source of sabotage 
through flooding the audit data with irrelevant entries. 

The log of printed and/or punched output will be the file of 
accountability forms and an online copy of the information 
printed on the driver control console. User terminal output 
will not be logged. The system control console output and 
the system log data will provioe the needed audit data for 
important system events not recorded elsewhere. 

The allocator process that handles tape drives will provioe 
a log of all tape requests, including denied requests. 

3.16.<* Audit Selectivity 

All processes will be treated the same by the audit system. 
The ring zero portion of the audit system will check the pes 
of a process to determine whether a given event shoulc be 
included in the audit data. This will provide a wide range 
of selectivity to the audit system. 

The audit flags in the Pds will be established at process 
creation time. Another data field will be acded to each 
entry in the PNT and SAT which will describe the events to 
be audited for each personid and projectid. At process 
creation time, the system control process will turn on the 
pds audit flags if the corresponding flag appears for the 
personid or projectid of the user. 
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Only the SSO will be able to turn off these flags in the PNT 
and SAT. The default value will be "on" for each new person 
or project registered by the System Administrator. 

The events which will be identified by separate audit flags 
will Include the following* 

access to classified segments* 

security related file system errors* 

awarding of special access privileges* 

illegal opcode faults* 

access mode related access violation faults* 

ring related access violation faults* 

audit calls from outer rings* 

other events identified during implementation. 

It is recommended that the audit flags normally be turned 
off for the AFOSC supplied subverter process* since it will 
only add noise to the audit data. However* on occasion* it 
may be desirable to audit the subverter process as an aic in 
testing the audit system itself. 

3.16.5 Audit Oata Reduction 

A simple data reduction and output formatting program will 
be provided to prepare audit data for Inspection. For each 
class of audit data, the program will recognize keyworcs 
corresponding to fields in the audit data* such as "segment 
name*" "userld," "error code*" etc. The user of the data 
reduction program (presumably the SSO) will supply a list of 
keywords and corresponding data Items, For example* if thp 
user specifies "error code! no access*" all entries in th< 
indicated audit data file will be printed for which thi 



•e 
he 
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error code field specifies "no access." A limited 
capability for the use of "AND, "OR," and "NOT" Boolean 
operations will be supporteo to enhance selectivity. The 
flle_output command can be used to direct output to a 
segment. 
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3.17 CONTROL AND AUDIT OF SYSTEM CHANGES 



3.17.1 Requirements 

Security conf iguratlor control ensures that all changes to 
the operating system are accounted for and verifies that 
these changes do not impare the security of the system. 

Procedures must be established to control ana audit system 
changes. Software tools must be provided to assist In the 
audit. AM security sensitive modules should be identified 
in each release. Source and object code have been provided 
for the initial release. Source and object cooe roust be 
provided for all revisions along with a listing of all 
modules modified and the reason for each modification within 
each module. 

3.17.2 New Release Material 

For each new release* will contain at least: 

A Multics system tape (MST); 

Machine readable source code of all modules charged 
from Multics. 80S, Salvager, and DATANET 355 systems? 

80S and Salvager object tape if the code has been 
changed? 

DATANET 355 object code it changed; 

Object code of all compilers, assemblers, and PL/I 
operators used to generate the changed modules; 

List of all modules changed with the reason for the 
change. 

3«17.3 Tools 

Procedures will be supplied to assist in comparison and 
auditing of system changes at source and object level. An 
ASCII comparison procedure will be supplied to aid in noting 
changes made to source code. A procedure which (takes a 
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5.0 PREPARATION FOR DELIVERY 



This section does not apply to this report 
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6.0 NOTES 



This section is for Administrative Information Only - Not 
Contractually Binding. 



6.1 Removable Media 

During the Oesign Analysis* the security reouirements for 
integrating removable media storage into the virtual memory 
was discussed. The term "demountable segments" has been 
used in this section to. differentiate removable media 
containing portions of the Multics storage system from 
removable media associated with I/O directed from a Mul tics 
process. 

The recommendations resulting from the Oesign Analysis 
discussions are included in this section because they are 
not a direct part of the implementation of security 
controls* However* the following recommendations will be 
used as guidelines by the project which is designing the 
demountable segment capability for Multics. 

6.1.1 Recommendations 

1. The demountable segment capability must allow the basic 
Multics access controls to be extended to removable storage 
media. Disk packs are the priirary type of media addressed, 
as the value of tapes in this role is not operationally 
clear at this time. 

2. Each physical disk pack must be identified as part of the 
system, such that it should be Impossible for It to be used 
by any process for direct I/O. 

3. There must be a unique machine readable header on each 
physical unit. No disk pack should be usable for 
demountable segments until the header has beer initialized 
by the system. This header should Identify the highest 
classification of information ever stored on the disk pacf«. 



■ "■ ■ 91 



